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Patent 

EXPRESS MAIL LABEL NO. EL388804975US Attorney Docket No.2028492-0002 



hJL«II9. in the united states PATENT AND TRADEMARK OFFICE 



REQUEST FOR FILING CONTINUATION/DIVISIONAL 
APPLICATION UNDER 37 C.F.R. S1.53fb) 




Box PATENT APPLICATION 

Assistant Commissioner for Patents i^>= 
Washington, D.C. 20231 

Sir: 

This is a request for filing a [ ] continuation [ X ] divisional application under 37 C.F.R. 
§ 1 .53(b) of pending Application No. 09/081.012 filed on May 19. 1998 , which is a continuation-in- 
part of Application No. 08/917.76L now issued as U.S. Patent No. 5,910,988 for REMOTE IMAGE 
CAPTURE WITH CENTRALIZED PROCESSING AND STORAGE, by the following named 
inventor: 

(a) Full Name Claudio R. BALLARD 

[ X ] The entire disclosure for the prior application from which a copy of the oath or declaration is 
supplied herewith is considered as being part of the disclosure of the accompanying appUcation and is 
hereby incorporated by reference therein. 

[ ] This application is being filed by less than all the inventors named in the prior application. In 
accordance with 37 C.F.R. § 1.63(d)(2), the Commissioner is requested to delete the name(s) of the 
following person or persons who are not inventors of the invention being claimed in this application 



(a) Full name 



1 . [ X ] Enclosed is a copy of the prior Application No. 09/08 LP 12 as originally filed on 

Mav 19, 1998 , including: 

40 pages of specification; 
14 pages of claims including claims 1-53; and 
1 page(s) of abstract. 

2. [ ] Enclosed is a revised prior application and a copy of the prior executed oath and 

declaration as filed. No new matter has been added to the revised application. 

3. [ X ] A copy of the statement(s) claiming small entity status is enclosed as 

filed in prior Application No. 09/081,012, filed on May 19, 1998. 
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4. [ X ] The filing fee is calculated below [ X ] and in accordance with the Preliminary Amendment: 







NO. OF 
CLAIMS 




EXTRA 
CLAIMS 


RAIL 




Basic Application Fee 


$ 760.00 


Total Claims 


13 


Minus 20 = 


0 


X $18.00 = 


0 


Independent 
Claims 


5 


Minus 3 = 


0 


X $78.00 = 


156.00 


If multiple depe 


ndent claims are j 


present, add $260 


00 


0 


Total Application Fee 




916.00 


If small entity status is claimed, subtract 50% of Total Application Fee 


458.00 


Add Assignment Recording Fee of $40.00 if Assignment document is enclosed 


0 




$ 458.00 



5. [ ] Charge $ to Deposit Account No. 13-0437 for the fee due. 



6. [ X ] Check No. 667419 in the amount of $ 458.00 is enclosed for the fee due. 

7. [ X ] The Commissioner is hereby authorized to charge any appropriate fees under 37 

C.F.R. §1.16, 1.17 and 1.21 that may be required by this paper, and to credit any 
overpayment, to Deposit Account No. 13-0437. This paper is submitted in triplicate. 

8. [ ] Cancel in this application original claims of the prior application before 

calculating the filing fee. (At least one original independent claim must be retained for filing 
purposes.) 

9. [ ] Amend the specification by inserting before the first line the sentence: -This 

application is a [ ] continuation, [ ] divisional, of Application No. 

filed . - 

1 0. [ ] Transfer the drawings from the pending prior application to this application and 

abandon said prior application as of the filing date accorded this application. A duplicate of 
this paper is enclosed for filing in the prior application file. (May only be used if signed by 
person authorized under 37 C.F.R. §1.138 and before payment of the issue fee.) 



1 1. [ X ] 1 1 pages of formal drawings including Figures 1-10 are enclosed. 
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12. [ ] Priority of Application No. 



filed on 



in (country) is claimed under 35 U.S.C. 



§119. 



[ ] The certified copy of the priority application 
[ ] is enclosed 

[ ] was filed on in prior Application No. 



, filed on 



[ ] has not yet been filed. 



13.[X] 



A Preliminary Amendment is enclosed. 



14.[X] 



Also enclosed an Information Disclosure Statement PTQ-1449 Form and copies of 
54 U.S. patents. 



15. [ X ] The original power of attorney in the prior application is enclosed together with a copy of 
the Supplemental Power of Attorney as filed in parent application Serial No. 09/081..012 

a. [ X ] The powers appear in the original papers in the prior apphcation. 

b. [ ] Since the power does not appear in the original papers, a copy of the power in 

the prior application is enclosed. 

c. [ ] Recognizes as Associate Attorney . 

d. [ X ] Address all future communications to: (May only be completed by applicant, 

or attorney of record.) 

J. Michael Martinez de Andino 
McGuire, Woods, Battle & Boothe, L.L.P. 
One James Center 
901 East Gary Street 
Richmond, Virginia 23219-4030 



Date 



December 6, 1999 




Address of Signator: 



McGuire, Woods, Battle & Boothe, L.L.P. 
One James Center 
901 EastCary Street 
Richmond, Virginia 23219-4030 



[ ] inventor(s) 

[ ] assignee of complete interest 
[ X ] attorney or agent of record 
[ ] filed under 37 C.F.R. § 1.34(a) 



IS THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In rc Application of: 
Qaudio R. BAJLLARD 

Application No.; To Be Assigned Group Art Unit: 

Filed: Herewith Examiner: 

For; REMOTE IMAGE CAPTURE WITH Attorney Docket No. : 

CENTRAUZED PROCESSING AND 2269-007 
STORAGE 



VERIFIED STATEMHMT (DECLARAHON) CLAIMING SMALL ENTITY STATUS 
[37 CFR l,9(f) and 1.27(c) J - Sm^l Business Concern 

Assistant Commissioner for Patents P^-^Sl'??;/?^^'^' 
Washington, D.C. 20231 



Sir: 

I hereby declare that I am an official of the small business concern empowered to act in behalf of 
the concern idendjSed below: 

CSP Holdings, LLC 
16 West Neck Court 
Lloyd Haibor, New York 11743 



I hereby declare that the above identified small business concern qualifies as a small business concern 
as defined in 37 CFR l-9(d), for purposes of paying reduced fees under section 41(a) and (b) of Title 
35, United States Code, in that the number of employees of the concern, including those of its 
affiliates, does not exceed 500 persons. For purposes of this statement, (1) the number of en^>ioyees 
of the business concern is the average over the previous fiscal year of the concern of the person 
employed on a full-time» part-time or temporary basis during each of the pay periods of the fiscal 
year, and (2) concerns are affiliates of each other when either, directly or indirectly, one concern 
controls or has the power to control the other, or a third party or parties controls or has the power 
to control both. 



I hereby declare that rights under contract or law have been conveyed to and remain with the small 
business concern and/or there is an obligation under contract or law by the invenior(s) to convey 
rights to the small business concern with regard to the invention, entitled REMOTE IMAGE 
CAPTURE yfrm centralized processing and storage by Claudio BALLARD 
described in the specification filed herewith. 

If the rights held by the above identified small business concern are not exclusive, each individual, ^iij^ J^^^ij^^^^^ 

concern or organization having rights to the invention is listed below and no rights to the invention 
are held by any person, other than the inventor, who could not qualify as an independent inventor 
under 37 CFR 1.9(c) if that person made the invention, or by any concern which would not qualify 
as a small business concern under 37 CFR 1.9(d), or a nonprofit organization under 37 CFR 1.9(e). 



FULL NAME: 
ADDRESS: 



□ INDrvnDDUAL □ SMALL BUSINESS CONCERN Q NONPROFrT ORGANiZATrON 



I acknowledge the duty to file, in this application or patent, notification of any change in status 
resulting in -loss of entitlement to small entity status prior to paying, or at the time of paying the 
earliest of the issue fee or any maintenance fee due after the date on which status as a small entity 
is no longer appropriate. [37 CFR 1.28 (b)) 

I hereby declare that all statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these statements were made 
with the knowledge diat willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such 
willful false statements may jeopardize the validity of the appUcation, and patent issuing thereon, or 
any patent to which this verified statement is directed. 

Send correspondence to: 



Direct telephone calls to: 



PENNIB & EDMONDS lip 
1667 K Street, N.W. 
Washmgton, D.C. 20006 



PENNIE & EDMONDS 
(202) 496-4400 



Name: 

Title: 

Address: 



Signature: 
Dace: 
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Attorney Docket No. 2028492-0002 
IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re US Patent Application of: 



Claudio R. BALLARD 

Serial No.: Unassigned 

Filing Date: December 6, 1999 

Title: REMOTE IMAGE CAPTURE 
WITH CENTRALIZED 
PROCESSING AND STORAGE 



Group Art Unit: Unassigned 
Examiner: Unassigned 



PRFXTMINARY AMENDMENT 

Assistant Commissioner for Patents 
Washington, D.C. 20231 

Sir: 

Prior to the examination of the present application, please amend the above-identified 
patent appUcation as follows: 

IN THE SPECIFICATION : 

Kindly amend the specification as follows: 

On page 1, after the title of the invention, insert the following information: 
- CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is a divisional of U.S. Patent Application Serial No. 09/081,012 which 
was filed on May 19, 1998, which is a continuation-in-part of U.S. Patent Application Serial No. 
08/917,761 which was filed on August 27, 1997 and has now issued as U.S. Patent No. 
5,910,988. - 



IN THE CLAIMS : 

Please cancel claims 1-41 and 51-53 without prejudice or disclaimer and amend the 
following claims: 
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42. (Amended) A communication network for the transmission of data within 
and between one or more remote data processing subsystems, at least one intermediate data 
collecting subsystem and at least one central subsystem forming a tiered architecture wherein 
each of said at least one central data processing subsystem communicate with a 
corresponding some of said at least one data collecting subsystem and each of said at least 
one data collecting subsystem communicate with a corresponding some of said one or more 
data processing subsystems , said data processing subsystem including an im aging subsystem 
for capturing images of checks, comprising: 

at least one first local area network for transmitting data including a payer bank's 
identification number, a payer bank's routing number, a payer bank's routing information, a 
payer's account number, a payer's check, a payer bank's draft, a check amount, a payee 
bank's identification number, a payee bank's routing information, and a payee's account 
number, within a corresponding one of said one or more remote subsystems; 

at least one second local area network for transmitting data within a corresponding 
one of said at least one intermediate subsystem; 

at least one third local area network for transmitting data within a corresponding one 
of said at least one central subsystem; and 

at least one wide area network for transmitting data between said one or more remote 
subsystems, said at least one intermediate subsystem and said at least one central subsystem. 

46. (Amended) A method for transmitting data within and between one or more 
remote subsystems, at least one intermediate subsystem and at least one central subsystem in 
a tiered maimer wherein each of the central subsystems communicate with at least one [a 
corresponding some of the] intermediate subsystem[s] and each of the intermediate 
subsystems communicate with at least one [a corresponding some of the] remote 
subsystem[s] comprising the steps of: 

capturing an image of checks and extracting data therefrom, said data including a 
payer bank's identification number, a payer bank's routing number, a payer bank's routing 
information, a payer's account number, a payer's check, a payer bank's draft, a check 
amount, a payee bank's identification number, a payee bank's routing inform ation, and a 
payee's account number, and further including; 
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transmitting data within the remote locations; 

transmitting data from each remote location to a corresponding intermediate location; 
transmitting data within the intermediate locations; 

transmitting data from each intermediate location to corresponding central locations; 

and 

transmitting data within the central locations. 

Please add new claims 54 -57 as follows: 

- 54. A communication network for the transmission of data within and between 
one or more remote data processing subsystems, at least one intermediate data collecting 
subsystem and at least one central subsystem forming a tiered architecture wherein each of 
said at least one central data processing subsystem communicate with a corresponding some 
of said at least one data collecting subsystem and each of said at least one data collecting 
subsystem communicate with a corresponding some of said one or more data processing 
subsystems, said data processing subsystem including an imaging subsystem for capturing 
images of checks and verifying the checks, comprising: 

at least one first local area network for transmitting data within a corresponding one 
of said one or more remote subsystems; 

at least one second local area network for transmitting data within a corresponding 
one of said at least one intermediate subsystem; 

at least one third local area network for transmitting data within a corresponding one 
of said at least one central subsystem; and 

at least one wide area network for transmitting data between said one or more remote 
subsystems, said at least one intermediate subsystem and said at least one central subsystem. 

55. A method for transmitting data within and between one or more remote 
subsystems, at least one intermediate subsystem and at least one central subsystem in a tiered 
manner wherein each of the central subsystems communicate with intermediate subsystem 
and each of the intermediate subsystems communicate with at least one remote subsystem 
comprising the steps of: 
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capturing an image of checks and extracting data therefrom; 
verifying the checks; 

transmitting data within the remote locations; 

transmitting data from each remote location to a corresponding intermediate location; 
transmitting data within the intermediate locations; 

transmitting data from each intermediate location to corresponding central locations; 

and 

transmitting data within the central locations. 

56. A method for central management, storage and verification of remotely captured 
paper transactions from documents and receipts comprising the steps of 

capturing and sending the paper transaction data at one or more locations; 
managing the capturing and sending of the transaction data; 

collecting, processing, sending and storing the transaction data at a central location; 

managing the collecting, processing, sending and storing of the captured transaction at 
a central location, including comparing captured transaction data to stored transaction data 
for verification; and 

transmitting the transaction data within and between the remote location(s) and the 
central location. 

57. A method for central management, storage and verification of remotely captured 
paper transactions from documents and receipts according to claim 56 wherein said step of 
managing the collecting, processing, sending and storing further comprises the step of 
performing said paper transaction by transferring funds electronically from a payer bank to a 
payee bank. — 

REMARKS 

By the present Preliminary Amendment, the specification has been amended to include a 
cross-reference to all related applications. Claims 1-41 and 51-53 have been canceled without 
prejudice or disclaimer , certain of the claims have been amended as amended in the parent 
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application and new claims 54-57 have been added to define the present invention with greater 
particularity. Claims 56 and 57 represent claims 51 and 53 rewritten in independent form. 
Favorable consideration is respectfully requested. 

Should any questions arise concerning this application, the Examiner is invited to contact 
the undersigned attorney at the telephone number provided below. 



McGuire, Woods, Battle & Boothe LLP 

One James Center 
901 East Cary Street 
Richmond, VA 23219-4030 
(804) 775-4338 

Date: December 6, 1999 



Respectfully Submitted, 




REMOTE IMAGE CAPTURE 
WITH CEKTRALI2ED PROCESSING AND STORAGE 

FIELD OF THE INVENTION 

5 This invention relates generally to the automated 

processing of docxments" and electronic data from different 
applications including sale, business, banking and general 
constuaer transactions. More particularly, it pertains to an 
automated system to retrieve transaction data at remote 
10 locations, to encrypt the data, to transmit the encrypted 

data to a central location, to transform the data to a usable 
form, to generate informative reports from the data and to 
transmit the informative reports to the remote locations. 

15 BACKGROUND 

This invention involves the processing of documents and 
electronic data which are generated, for example, from sale, 
business and banking transactions including credit card 
transactions, smart card transactions, automated teller 
20 machine (ATM) transactions, consiimer purchases, business 
forms, W2 forms, birth certificates, deeds and insurance 
documents . 

The enormous number of paper and electronic records 
generated from documents and electronic data from sale, 

25 business and banking transactions contain valuable 

information. First, these paper and electronic records 
contain information which can be used to verify the accuracy 
of the records maintained by consumers, merchants and 
bankers. For example, customers use paper receipts of sale 

30 and banking transactions to verify the information on the 
periodic statements which they receive from their bank or 
credit card institution. Merchants use paper receipts to 
record sale transactions for management of customer 
complaints. Taxpayers use paper receipts to record tax 

35 deductible contributions for use in their tax return 

preparation. Employees use paper receipts to record business 
expenses for preparation of business expense forms. 
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Paper and electronic records also contain information 
which can be used for market analysis. For example, 
manufacturers and retailers can determine consximer 
preferences in different regions as well as trends in 
5 consumer preferences from the information contained in paper 
and electronic records/ 

However, the maintenance and processing of paper and 
electronic records presents difficult challenges. First, 
paper receipts and dociiments could easily be lost, misplaced, 
10 stolen, damaged or destroyed. Further, the information 
contained in these paper and electronic records cannot be 
easily processed because it is scattered among individual 
records. For example, the market trend information contained 
in a group of sales records retained by merchants cannot 
15 easily be determined since this information is scattered 

among the individual records. Likewise, the tax information 
contained in a group of paper receipts of sales transactions 
retained by consumers cannot easily be processed. 

Previous approaches have been proposed to meet the 

2 0 challenges associated with the maintenance and processing of 

paper and electronic records. For example, data archive 
service companies store the information from paper receipts 
and documents acquired from their customers on microfilm or 
compact disc read only memory (CD-ROM) at a central facility. 
25 Customers typically deliver the paper receipts and documents 
to the central facility. For sensitive documents which 
cannot leave the customer site, some data archive service 
companies perform data acquisition and transfer to magnetic 
tapes at the customer site and deliver the tapes to the 

3 0 central facility. 

The approach offered by these data archive service 
companies have disadvantages. First, the approach is costly 
and has poor performance because it requires an expensive, 
time consuming physical transportation of paper receipts or 
35 magnetic tapes from the customer site to the central 
facility. Further, the approach is not reliable as 
information can be lost or damaged during physical 
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transportation. The approach also has limited capability as 

it does not process electronic records along with the paper 

receipts within a single system. 

Other approaches have focused on the elimination of 
5 paper receipts and dociments. U.S. Patent No, 5,590,038 

discloses a universal electronic transaction card (UET card) 

or smart card which stores transaction information on a 

memory embedded on the card as a substitute for a paper 

receipt- Similarly, U.S. Patent No. 5,479,510 discloses a 
10 method of electronically transmitting and storing purchaser 

information at the time of purchase which is read at a later 

time to ensure that the purchased goods or services are 

delivered to the correct person. 

While these approaches avoid the problems associated :>^?>r£H^^^i';^^^^^ 
15 with paper receipts, they have other disadvantages. First, 

these approaches do not offer independent verification of the 

accuracy of the records maintained by consumers, merchants 

and bankers with a third party recipient of the transaction 

data. For example, if a UET card is lost, stolen, damaged or 
20 deliberately altered by an unscrupulous holder after 

recording sale or banking transactions, these approaches 

would not be able to verify the remaining records which are 

maintained by the other parties to the transactions. 

Next, these approaches do not have the ability to 
25 process both paper and electronic records of transactions 

within a single, comprehensive system. Accordingly, they do 

not address the task of processing the enormous number of 

paper receipts which have been generated from sales and 

banking transactions. The absence of the ability to process 
3 0 both paper and electronic records of these approaches is a 

significant limitation as paper receipts and documents will 

continue to be generated for the foreseeable future because 

of concerns over the reliability and security of electronic 

transactions and the familiarity of consximers and merchants 
35 with paper receipts. ^g|;pil5!fe|i?!K 
These approaches also have a security deficiency as they 

do not offer signature verification which is typically used 
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on credit card purchases to avoid theft and fraud. For 
example, a thief could misappropriate money from a UET card 
holder after obtaining by force, manipulation or theft the 
user's personal identification number (PIN). Similarly, it 
5 is not uncommon for criminals to acquire credit cards in 
victims' names and make unlawful charges after obtaining the 
victim's social security number. This becomes a greater 
concern as that type of personal information becomes 
available, e.g., on the internet. Also, the signature 

10 verification performed manually by merchants for credit card 
purchases frequently misses forged signatures. 

Even if smart cards or UET cards had the ability to 
store signature and other biometric data within the card for 
verification, the system would still have disadvantages. 

15 First, the stored biometric data on the card could be altered 
by a card thief to defeat the security measure. Similarly, 
the biometric data could be corrupted if the card is damaged. 
Finally, the security measure would be costly at it would 
require an expensive biometric comparison feature either on 

2 0 each card or on equipment at each merchant site. 

Additional biometric verification systems including 
signature verification systems have been proposed to address 
the security problem. For example, U.S. Patent 5,657,393 
discloses a method and apparatus for verification of hand- 

25 written signatures involving the extraction and comparison of 
signature characteristics including the length and angle of 
select component lines. In addition, U.S. Patent 5,602,933 
discloses a method and apparatus for the verification of 
remotely acquired data with corresponding data stored at a 

30 central facility. 

However, none of these verification systems offer 
general support for transaction initiation, remote paper and 
electronic data acquisition, data encryption, data 
communication , data archival, data retrieval, data mining, 

35 manipulation and analytic services. Accordingly, there is a 
need for a single system which offers comprehensive support 
for the tasks involved in the automated processing of 
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documents, biometric and electronic data from sale, business, 
banking and general consumer transactions. Further, there is 
a need for a single comprehensive system having the 
reliability, per f oinnance , fault tolerance, capacity, cost and 
5 security to satisfy the requirements of the retail, business, 
banking and general consumer industries. 

SUMMARY OF THE INVENTION 

The invention provides an automated, reliable, high 

10 performance, fault tolerant, and low cost system with maximal 
security and availability to process electronic and paper 
transactions, and has been named the DataTreasury™ System. 

It is an object of the present invention to provide a 
system for central management, storage and verification of 

15 remotely captured electronic and paper transactions from 
credit cards, smart cards, debit cards, documents and 
receipts involving sales, business, banking and general 
purpose consumer applications comprising: 

at least one remote data access subsystem for capturing 

20 and sending electronic and paper transaction data; 

at least one data collecting subsystem for collecting 
and sending the electronic and paper transaction data 
comprising a first data management subsystem for managing the 
collecting and sending of the transaction data; 

25 at least one central data processing subsystem for 

processing, sending and storing the electronic and paper 
transaction data comprising a second data management 
subsystem for managing the processing, sending and storing of 
the transaction data; and 

3 0 at least one communication network for the transmission 

of the transaction data within and between said at least one 
data access subsystem and said at least one data processing 
subsystem. 

The DataTreasury™ System processes paper and/or 
35 electronic receipts such as credit card receipts, Automated 
Teller Machine (ATM) receipts, business expense receipts and 
sales receipts and automatically generates reports such as 
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credit card statements^ bank statements, tax reports for tax 
return preparation, market analyses, and the like. 

It is a further object of the DataTreasury™ System to 
retrieve both paper and electronic transactions at remote 
5 locations • 

It is a further object of the DataTreasury™ System to 
employ a scanner and a data entry terminal at a customer site 
to retrieve data from paper transactions and to enable 
additions or modifications to the scanned information 

10 respectively. 

It is a further object of the DataTreasury™ System to 
provide an input device for retrieving transaction data from 
the memory of smart cards for independent verification of the 
records maintained by consumers, merchants and bankers to 

15 prevent the loss of data from the loss, theft, damage or 
deliberate alteration of the smart card. 

It is a further object of the DataTreasury™ System to 
retrieve and process transaction data from DataTreasury'** 
System anonymous smart cards which are identified by an 

2 0 accoxint number and password. Since DataTreasury"* System 
anonymous smart card transactions can be identified without 
the customer's name, a customer can add money to the 
DataTreasury™ System anonymous smart card and make 
expenditures with the card with the same degree of privacy as 

25 cash acquisitions and expenditures. 

It is a further object of the DataTreasury™ System to 
retrieve customer billing data from employee time documents 
and to generate customer billing statements from the billing 
data- 

30 It is a further object of the DataTreasury™ System to 

initiate electronic transactions including transactions on 
the internet and to provide identification verification by 
capturing and comparing signature and biometric data. 

35 It is a further object of the DataTreasury™ System of 

the invention to process electronic and paper transactions 
with a tiered architecture comprised of DataTreasury™ System 
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Access- Terminals (DATs) , DataTreasury™ System Access 
Collectors (DACs) and DataTreasury"* System Processing 
Concentrators (DPCs) . 



5 BRIEF DESCRIPTION OF THE DRAWINGS 

These and other objects and features of the invention 
will be more clearly understood from the following detailed 
description along with the accompanying drawing figures, 
wherein: 

10 FIG. 1 is a block diagram showing the three major 

operational elements of the invention: the DataTreasury™ 
System Access Terminal (DAT) , the DataTreasury™ System Access 
Collector (DAC) and the DataTreasury™ System Processing 
Concentrator (DPC) ; 

15 FIG. 2 is a block diagram of the DAT architecture; 

FIG. 3a is a flow chart describing image capture by a 

DAT; 

FIG. 3b displays a sample paper receipt which is 
processed by the DAT; 
20 FIG. 4 is a block diagram of the DAC architecture; 

FIG. 5 is a flow chart describing the polling of the 
DATs by a DAC; 

FIG. 6 is a block diagram of the DPC architecture; 
FIG. 7 is a flow chart describing the polling of the 
25 DACs by the DPC; 

FIG. 8 is a flow chart describing the data processing 
performed by the DPC; and 

FIG. 9 is a flow chart describing the data retrieval 
performed by the DPC; and 
30 FIG. 10 is a flow chart describing the use of the 

DataTreasury™ system to process personal checks. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

FIG- 1 shows the architecture of the DataTreasury™ 
35 System 100, The DataTreasury™ System 100 has three 
operational elements: the DataTreasury™ System Access 
Terminal (DAT) 200 (the remote data access subsystem) , the 
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DataTreasury™ System Access Collector (DAC) 400 (the 
intermediate data collecting subsystem) , and the 
DataTreasury™ System Processing Concentrator (DPC) 600 (the 
central data processing subsystem) . 
5 The DataTreasury™ System 100 architecture consists of 

three tiers. At the bottom tier, the DATs 200 retrieve data 
from the customer sites. At the next tier, the DACs 400 poll 
the DATs 200 to receive data which accximulates in the DATs 
200. At the top tier, the DPCs 600 poll the DACs 400 to 

10 receive data which accumulates in the DACs 400. The DPCs 600 
store the customer's data in a central location, generate 
informative reports from the data and transmit the 
informative reports to the customers at remote locations. 

In the preferred embodiment, the DataTreasury™ System 

15 100 complies with the Price Waterhouse SAS70 industry 

standard. Specifically, the DataTreasury™ System 100 meets 
the software development standard, the system deployment 
standard and the reliability standard specified by Price 
Waterhouse SAS70. By adhering to the Price Waterhouse SAS70 

2 0 standard, the DataTreasury™ System 100 provides the security, 
availability and reliability required by mission critical 
financial applications of banks and stock brokerage 
companies • 

As is known to persons of ordinary skill in the art, the 
25 DataTreasury™ System 100 could also use other software 

development standard, other system deployment standards and 
other reliability standards as long as adherence to these 
alternative standards provides the security, availability and 
reliability required by mission critical financial 
30 applications. 

FIG. 2 shows a block diagram of the DAT 200 
architecture. DATs 200 are located at customer sites. The 
DataTreasury™ System 100 customers include merchants, 
consumers and bankers. The DATs 200 act as the customer 
35 contact point to the suite of services provided by the 

DataTreasury™ System 100. In the preferred embodiment, the 
DAT 200 is custom designed around a general purpose thin 
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client Network Computer (NC) which runs SUN Microsystem's 
JAVA/OS operating system. The custom designed DAT 200 
comprises a DAT scanner 202, a DAT modem 204, DAT digital 
storage 206, a DAT controller 210 (workstation), a DAT card 
5 interface 212, an optional DAT printer 208 and a signature 
pad 214. 

As is known to persons of ordinary skill in the art, the 
DAT 200 could also be custom designed around a general 
purpose network computer running other operating systems as 

10 long as the chosen operating system provides support for 
multiprocessing, memory management and dynamic linking 
required by the DataTreasury™ System 100, 

The DAT scanner 202 scans a paper receipt and generates 
a digital bitmap image representation called a Bitmap Image 

15 (BI) of the receipt- In the preferred embodiment, the DAT 
scanner 202 has the ability to support a full range of image 
resolution values which are commonly measured in Dots Per 
Inch (DPI) . Next, the DAT scanner 202 has the ability to 
perform full duplex imaging. With full duplex imaging, a 

2 0 scanner simultaneous captures both the front and back of a 
paper document. The DAT scanner 202 can also support gray 
scale and full color imaging at any bit per pixel depth 
value. The DAT scanner 202 also supports the capture of 
hand-written signatures for identity verification. 

2 5 In addition to scanning images and text, the DAT scanner 

202 also scans DataGlyph™ elements, available from Xerox 
Corporation. As is known to persons of ordinary skill in the 
art, the Xerox DataGlyph"** Technology represents digital 
information with machine readable data which is encoded into 

30 many, tiny, individual glyph elements. Each glyph element 
consists of a 45 degree diagonal line which could be as short 
as 1/ 100th of an inch depending on the resolution of the 
scanning and printing devices. Each glyph element represents 
a binary 0 or 1 depending on whether it slopes downward to 

35 the left or the right respectively. Accordingly, DataGlyph™ 
elements can represent character strings as ASCII or EBCIDIC 
binary representations. Further, encryption methods, as 
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known -to persons of ordinary skill in the art encrypt the 
data represented by the DataGlyph™ Technology. 

The use of glyph technology in the DataTreasury™ System 
100 improves the accuracy, cost and performance of the 
5 system. Xerox DataGlyph"* Technology includes error 

correction codes which can be referenced to correct scanning 
errors or to correct damage to the docxment caused by ink 
spills or ordinary wear. DataGlyph™ Technology also leads to 
decreased system cost since the system will require less 

10 manual inteirvention for data entry and correction because of 
the improved accuracy associated with DataGlyph™ elements. 
Since DataGlyph™ elements represent a large amount of 
information in a small amount of space, the DAT scanner 100 
will require a small amount of time to input a large amount 

15 of information. 

The DAT card interface 212 and the DAT signature pad 214 
along with the internet and telephone access through the DAT 
modem 2 04 enable the DataTreasury™ System 100 customer to 
initiate secure sale and banking transactions via the 

20 internet or telephone with the DAT 200 using a variety of 
cards including debit cards, smart cards and credit cards. 
After selecting a purchase or a banking transaction through a 
standard internet interface, the DataTreasury™ System 100 
customer inserts or swipes the debit card, smart card or 

25 credit card into the DAT card interface 212. 

The DAT card interface 212 retrieves the identification 
information from the card for subsequent transmission to the 
destination of the internet transaction. Further, the DAT 
scanner 202 could capture a hand written signature from a 

30 document or the DAT signature pad 214 could capture an 
electronic signature written on it with a special pen. 
Similarly, these security features allow a credit card 
recipient to activate the card with a DAT 200 located at a 
merchant site. The security features would detect 

35 unauthorized use of debit cards, credit cards and smart cards 
resulting from their unlawful interception. Accordingly, the 
DataTreasury™ System's 100 security features offer a more 
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secure alternative for internet and telephone transactions 
than the typical methods which only require transmission of a 
card account number and expiration date. 

As is known to persons of ordinary skill in the art, the 
5 DATs 2 00 could also include additional devices for capturing 
other biometric data for additional security. These devices 
include facial scans, fingerprints, voice prints, iris scans, 
retina scans and hand geometry. 

In addition to initiating sale and banking transactions, 

10 the DAT card interface 212 also reads sale and banking 
transactions initiated elsewhere from the memory of smart 
cards to enable subsequent storage and processing by the 
DataTreasury™ System. If a smart card is lost, stolen, 
damaged or deliberately altered by an unscrupulous holder 

15 after the DAT card interface 212 reads its transaction data, 
the DataTreasury™ System 100 can reproduce the transaction 
data for the customer. Accordingly, the DAT card interface 
212 provides support for independent verification of the 
records maintained by consumers, merchants and bankers to 

20 prevent the loss of data from the loss, theft, damage or 
deliberate alteration of the smart card. 

The DAT card interface 212 also supports the initiation 
and retrieval of sale and banking transactions with the 
DataTreasury™ System anonymous smart cards. In contrast to 

25 standard debit cards and credit cards, the DataTreasury™ 
System anonymous smart card does not identify the card's 
holder by name. Instead, the DataTreasury™ System anonymous 
smart card requires only an account number and a password. 
Since DataTreasury™ System anonymous smart card transactions 

30 can be identified without the customer's name, a 
DataTreasury™ System 100 customer can purchase a 
DataTreasury™ System anonymous smart card, add money to the 
card, make expenditures with the card and monitor the card's 
account with the same degree of privacy as cash acquisition, 

3 5 expenditure and management. 

The DAT scanner 202, the internet access, the signature 
pad 214 and other biometric data capture devices also support 
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the remote capture of survey information and purchase orders. 
For example, the DAT scanner 202 captures surveys appearing 
on the back of checks at restaurants and bars- Similarly, 
the DAT scanner 202 could capture purchase orders from 
5 residences, enabling customers to make immediate purchases 
from their home of goods promoted through the mail. 
Accordingly, home marketing merchant could transmit sales in 
a more cost efficient and reliable manner by using the DAT 
scanner 202 instead of providing envelopes with prepaid 

10 postage to residences. 

The DAT scanner 202 also captures receipts which are 
subsequently needed for tax return preparation or tax audits. 
Similarly, the DAT scanner 202 captures sales receipts from 
merchants, providing an off-site secure, reliable repository 

15 to guard against loss resulting from flooding, fire or other 
circumstances. This feature could also allow a merchant to 
automatically perform inventory in a reliable and cost- 
effective manner. 

The DAT controller 210 performs processing tasks and 

20 Input/Output (I/O) tasks which are typically performed by a 
processor. The DAT controller 210 compresses, encrypts and 
tags the BI to form a Tagged Encrypted Compressed Bitmap 
Image (TECBI) . The DAT controller 210 also manages the 
Input/Output (I/O). Specifically, the DAT controller 210 

25 manages devices like the DAT scanner 202, the DAT digital 
storage 206, the optional DAT printer 208 and the DAT modem 
204. 

The DAT digital storage 208 holds data such as the 
TECBI- The DAT modem 204 transmits data from the DAT 200 to 

30 the appropriate DAC 400 as instructed by the DAT controller 
210. Specifically, the DAT modem 204 transmits the TECBIs 
from the DAT digital storage 208 to the appropriate DAC 400. 
In the preferred embodiment, the DAT modem 204 is a high 
speed modem with dial-up connectivity. The DAT digital 

35 storage 208 is sufficiently large to store the input data 
before transmission to a DAC 400. The DAT digital storage 
2 08 can be Random Access Memory (RAM) or a hard drive. 
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FIG. 3a is a flow chart 300 describing the operation of 
the DAT in detail- In step 310, the DAT scanner 202 scans 
paper receipts into the DAT 200 provided by an operator. In 
step 312, the DAT controller 210 determines whether the 
5 operation executed successfully. If the scanning is 

successful, the DAT scanner 202 produces a Bitmap Image (BI) . 
If the scanning is unsuccessful, the DAT controller 210 
notifies the operator of the trouble and prompts the operator 
for repair in step 370. 

10 If a BI is created, the DAT controller 210 executes a 

conventional image compression algorithm like the Tagged 
Image File Format (TIFF) program to compress the BI in step 
314. In step 316, the DAT controller 210 determines whether 
the compression executed successfully. If the compression is 

15 successful, it produces a Compressed Bitmap Image (CBI) . If 
the compression is unsuccessful, the DAT controller 210 
notifies the operator of the trouble and prompts the operator 
for repair in step 370. 

If a CBI is created, the DAT controller 210 executes an 

20 encryption algorithm which is well known to an artisan of 
ordinaary skill in the field to encrypt the CBI in step 318. 
Encryption protects against unauthorized access during the 
subsequent transmission of the data which will be discussed 
below. In step 320, the DAT controller 210 determines 

25 whether the encryption operation executed successfully. If 
the encryption is successful, it produces an Encrypted 
Compressed Bitmap Image (ECBI) , If the encryption is 
unsuccessful, the DAT controller 210 notifies the operator of 
the trouble and prompts the operator for repair in step 370. 

3 0 If an ECBI is created, the DAT controller 210 tags the 

ECBI with a time stamp which includes the scanning time, an 
identification ntimber to identify the merchant originating 
the scan and any additional useful information in step 322, 
In step 324, the DAT controller 210 determines whether the 

35 tagging operation executed successfully. If the tagging is 
successful, it produces a Tagged Encrypted Compressed Bitmap 
Image (TECBI) . If the tagging is unsuccessful, the DAT 
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controller 210 notifies the operator of the trouble and 
prompts the operator for repair in step 370. 

If a TECBI is created, the DAT controller 210 stores the 
TECBI in the DAT digital storage 208 in step 326. In step 
5 328, the DAT controller 210 determines whether the storing 
operation executed successfully. If the storing operation is 
successful, the DAT digital storage 208 will contain the 
TECBI. If the storing operation is unsuccessful, the DAT 
controller 210 notifies the operator of the trouble and 

XO prompts the operator for repair in step 370. 

If the TECBI is properly stored in the DAT digital 
storage 208, the DAT controller 210 determines whether all 
paper receipts have been scanned in step 330. If all paper 
receipts have not been scanned, control returns to step 310 

15 where the next paper receipt will be processed as discussed 
above. If all paper receipts have been scanned, the DAT 
controller 210 asks the operator to verify the number of 
scanned receipts in step 334. If the number of scanned 
receipts as deterained by the DAT controller 210 does not 

20 equal the number of scanned receipts as determined by the 
operator, the DAT controller 210 asks whether the operator 
desires to rescan all of the receipts in step 338. 

If the operator chooses to rescan all of the receipts in 
step 338, the DAT controller 210 will delete all of the 

25 TECBIs associated with the batch from the DAT digital storage 
208 in step 342- After the operator prepares the batch of 
receipts for rescan in step 346, control returns to step 310 
where the first receipt in the batch will be processed as 
discussed above, 

30 If the operator chooses not to rescan all of the 

receipts from the batch in step 3 38, control returns to step 
334 where the DAT controller 210 asks the operator to verify 
the number of scanned receipts as discussed above. 

If the nvimber of scanned receipts as determined by the 

35 DAT controller 210 equals the number of scanned receipts as 
determined by the operator, the DAT controller 210 prints a 
batch ticket on the DAT printer 2 06 in step 3 50. The 
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operator will attach this batch ticket to the batch of 
receipts which have been scanned. This batch ticket shall 
contain relevant session information such as scan time, 
number of receipts and an identification number for the data 
5 operator. If processing difficulties occur for a batch of 
receipts after the image capture of flowchart 300, the batch 
ticket will enable them to be quickly located for rescanning 
with the DAT 200. 

In step 354, the DAT controller 210 determines whether 

10 the scan session has completed. If the scan session has not 
completed, control returns to step 310 where the first 
receipt in the next batch of the scan session will be 
processed as discussed above. If the scan session has 
completed, the DAT controller 210 selectively prints a 

15 session report on the DAT printer 206 in step 358. The DAT 
controller 210 writes statistical information for the session 
to the DAT digital storage 2 08 in step 362. In step 3 66, the 
DAT controller 210 terminates the session. 

FIG. 3b displays a sample paper receipt which is 

20 processed by the DAT 200 as described by the flowchart in 
FIG. 3a. The sample paper receipt involves a credit card 
transaction which has four participants: 

A. The ISSUER : is an entity such as a bank or corporate 
financial institution such as GE Capital, GM or AT&T which 

25 provides the credit behind the credit card and issues the 
card to the consumer. 

B. The PROCESSOR : executes the processing of an 
inbound credit card transaction by performing basic 
transaction validation that includes checking with the ISSUER 

30 database to ensure that the credit card has sufficient credit 
to allow approval of the transaction. 

C. The ACQUIRER : specializes in the marketing, 
installation and support of Point Of Sale (POS) credit card 
terminals. The acquirer, like the DAC 4 00 in the 

35 DataTreasury™ System 100 acts as an electronic collection 
point for the initial credit card transaction as the card is 



- 15 - 



PEDC-9 3 96 5 3 



insertred into the POS terminal. After acquisition, the 
acquirer passes the transaction to the PROCESSOR. 

D- The MERCHANT I inserts a credit card into a POS 
terminal and enters the amount of the transaction to initiate 
5 the credit card transaction. 

In the preferred embodiment, the DAT 200 reads the 
following information from the sample paper receipt shown in 
FIG. 3b and stores the information in the format described 
below. 

10 CUSTOMERJCD 370 : This field is a 7 position HEX 

numeric value. This field uniquely identifies the customer 

using the terminal. In this sample, this field would 

identify the credit card merchant. 

TERMINAL_ID 372: This field is a 6 position decimal 
15 numeric value. This field uniquely identifies the credit 

card terminal which is used to print the credit card receipt. 
TRANSACTION_DATE 37 Az This field contains the date and 

time of the credit card transaction. 

TRANSACTION _LINE_ITEM 376: This field is a variable 
20 length character string. The first three positions represent 

a right justified numeric field with leading zeros indicating 

the full length of this field. This field contains all data 

pertaining to the purchased item including the item's price. 

The DAT 200 will store a TRANSACTION_LINE_ITEM field for each 
25 transaction line item on the receipt. This field is optional 

since not all credit card transactions will have line items, 
TRANSACTION ^SUBTOTAL 378: This field is a double 

precision floating point number. This field indicates the 

subtotal of the TRANSACT I ON_LI NE_I T EMs . 
30 TRANSACTION _SALES_T AX 380: This field is a double 

precision floating point ntimber. This field contains the 

sales tax of the TRANSACTION_SUBTOTAIi. 

TRANSACTION ^AMOUNT 382: This field is a double 

precision floating point number. This field is the sum of 
35 the TRANSACTION SUBTOTAL and TRANSACTION SALES TAX. 
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CREDIT _CARD_ACCTJiUH 384: This field is a 12 position 
decimal value. This field identifies the credit card which 
was used to execute this transact ion - 

CREDIT _C ARB _EXP_D ATE 386: This field identifies the 
5 expiration date of the credit card. 

TRANSACTION^APPROVALjCODE 388: This field is a 6 
position nimeric value. This field indicates the approval 
code that was given for the particular transaction. 

The DAT 200 also stores additional items which are not 
10 pictured in FIG. 3b as described below: 

ISSUER_ID: This field is a 7 position decimal numeric 
value. This field identifies the credit card issuer. 

ACQUIRER_ID: This field is a 7 position decimal numeric 
value. This field identifies the acquirer. 
IS PROCESSOR^IDi This field is a 7 position decimal 

numeric value. This field identifies the processor. 

TRANSACTION _JiIiiE_ITEM_CNT I This field is a 3 position 
decimal numeric value. This field identifies the number of 
transaction line items on the receipt. A value of ZERO 
20 indicates the absence of any transaction line items on the 
receipt. 

TRANSACTION _GRATUITY I This field is a double precision 

floating number. This field is optional because it will only 

appear on restaurant or bar receipts. 
25 FINALjrRANSACTION_AMOUNTi This field is a double 

precision floating number. This field is optional because it 

will only appear on restaurant and bar receipts. The field 

is the svim of the TRANSACTION_AMOXJNT and 

TRANSACTION_GRATUITY . 
30 The tag prepended to the ECBI in step 3 22 of the 

flowchart of FIG. 3a identifies the time and place of the 

document's origination. Specifically, the tag consists of 

the following fields: 

DATJTERMINAL^IDz This field is a 7 position hexadecimal 
35 numeric value. This field uniquely identifies the DAT 200 

which is used by the customer. 
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DAT_SESSIONJDATEi This field identifies the date and 
time of the DAT 200 session which generated the image of the 
document . 

DATJJSER_IDi This field is a 4 position decimal numeric 
5 value* This field identifies the individual within the 
CUSTOMER'S organization who initiated the DAT 200 session. 

DATAjSLYPH_RESULTt This field is a variable length 
character string. The first four positions hold a right 
justified numeric position with leading zero which indicate 

10 the length of the field. The fifth position indicates the 
DataGlyph™ element status. A value of 0 indicates that the 
data glyph was NOT present on the receipt. A value of l 
indicates that the data glyph WAS PRESENT and contained no 
errors. A value of 2 indicates that the data glyph WAS PRESENT 

15 and had nominal errors. If the fifth position of this field 
has a value of 2, the remaining portion of the string 
identifies the erroneous field numbers. As subsequently 
described, the DPC 600 will reference this portion of the 
field to capture the erroneous data from the receipt with 

2 0 alternate methods. A value of 3 indicates that the data 

glyph WAS PRESENT WITH SEVERE ERRORS. In other words, a value 
3 indicates the DataGlyph™ element was badly damaged and 
unreadable. 

The receipt shown in FIG. 3b can also contain a 
25 signature which can be captured by the DAT scanner 202. A 
data glyph could identify the location of the signature on 
the receipt. 

As is known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 can also process receipts with 

3 0 alternate formats as long as the receipt contains the 

appropriate identification information such as the 
transaction amount, the customer, the DAT 200^ the 
transaction date, the transaction tax, the credit card 
number, the credit card expiration date, etc. 
35 The DataTreasury™ System 100 partitions the paper 

receipt into image snippets as illustrated by the sample on 
FIG. 3b. Partitioning facilitates an improvement in the 
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process to correct errors from the scanning operation. If an 
error occurred during scanning, the DataTreasury™ System 100 
corrects the error using manual entry. With partitioning, 
the DataTreasury™ System 100 focuses the correction effort on 
5 only the image snippet having the error instead of correcting 
the entire document. The subsequently discussed schema of 
the DataTreasury™ System 100 database describes the 
implementation of the partitioning concept in detail. 
The DACs 400 form the backbone of the tiered 

10 architecture shown in FIG. 1 and FIG. 4. As shown in FIG. 1, 
each DAC 400 supports a region containing a group of DATs 
200. Each DAC 400 polls the DATs 200 in its region and 
receives TECBIs which have accumulated in the DATs 200. The 
DACs 400 are located at key central sites of maximum merchant 

15 density. 

In the preferred embodiment, the DAC server 402 
comprises stand-alone Digital Equipment Corporation (DEC) SMP 
Alpha 4100 2/566 servers which are connected on a common 
network running Windows NT. The DEC Alpha servers manage the 

20 collection and intermediate storage of images and data which 
are received from the DATs 200. 

As is known to persons of ordinary skill in the art, the 
DataTreasury™ System 100 could use any one of a number of 
different servers that are available from other computer 

25 vendors as long as the server meets the capacity, performance 
and reliability requirements of the system. 

In the preferred embodiment, the DAC server 402 also 
comprises EMC 3300 SYMMETRIX CUBE Disk Storage Systems, which 
store the images and data collected and managed by the DEC 

3 0 Alpha servers. The DAC 400 architecture also uses a 

SYMMETRIX Remote Data Facility (SRDF) , available from EMC, to 
enable multiple, physically separate data centers housing EMC 
Storage Systems to maintain redundant backups of each other 
across a Wide Area Network (WAN) . Since SRDF performs the 

35 backup operations in the background, it does not affect the 
operational performance of the DataTreasury™ System 100, The 
DAC server 4 02 also has secondary memory 410. In the 
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preferred embodiment, the secondary memory 410 is a small 
scale DLT jukebox. 

The DAC Alpha servers of the DAC server 402 insert 
images and data received from the DATs 200 into a database 
5 which is stored on the disk storage systems using a data 

manipulation language as is well known to persons of ordinary 
skill in the art. In the preferred embodiment, the database 
is a relational database available from Oracle. 

As is well known to persons of ordinary skill in the 

10 art, the DataTreasury™ System 100 could use any one of a 

number of different database models which are available from 
other vendors including the entity relationship model as long 
as the selected database meets the storage and access 
efficiency requirements of the system. See, e.g., Chapter 2 

15 of Database System Concepts by Korth and Silberschatz . 

The DAC 400 architecture uses a WEB based paradigm using 
an enhanced Domain Name Services (DNS) , the Microsoft 
Component Object Model (DCOM) , and Windows NT Application 
Program Interfaces (APIs) to facilitate communication and 

20 load balancing among the servers comprising the DAC server 
402. As is known to persons of ordinary skill in the art^ 
DNS, which is also known as Bind, statically translates name 
requests to Internet Protocol 4 (IP4) addresses. In the DAC 
4 00 architecture, an enhanced DNS dynamically assigns IP4 

25 addresses to balance the load among the servers comprising 
the DAC server 402. 

In the preferred embodiment, the enhanced DNS is 
designed and implemented using objects from Microsoft DCOM. 
Using the DCOM objects, the enhanced DNS acquires real-time 

30 server load performance statistics on each server comprising 
the DAC server 4 02 from the Windows NT API at set intervals. 
Based on these load performance statistics, the enhanced DNS 
adjusts the mapping of name requests to IP4 addresses to 
direct data toward the servers which are more lightly loaded - 

35 A large bank of modems 404 polls the DATs 200 at the 

customer sites within the DAC's 400 region. In the preferred 
embodiment, the bank of modems 404, available as CISCO 
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AS520O, is an aggregate 48 modem device with Local Area 
Network (LAN) 406 connectivity which permits the DAC servers 
4 02 to dial the DATs 200 without requiring 48 separate modems 
and serial connections. 
5 The DAC servers 402 and the bank of modems 404 are 

connected on a LAN 406/ In the preferred embodiment, the LAN 
uses a switched lOOBaseT/lOBaseT communication hardware layer 
protocol. As is known to persons of ordinary skill in the 
art, the lOOBaseT/lOBaseT protocol is based on the Ethernet 

10 model. Further, the numbers 100 and 10 refer to the 

communication link speed in megabits per second. In the 
preferred embodiment, the CISCO Catalyst 2900 Network Switch 
supports the LAN 4 06 connectivity between the devices 
connected to the LAN 406 including the DAC servers 402 and 

15 the bank of modems 4 04. 

As is known to persons of ordinary skill in the art, 
alternate LAN architectures could be used to facilitate 
communication among the devices of the LAN 406. For example, 
the LAN 406 could use a hub architecture with a round robin 

20 allocation algorithm, a time division multiplexing algorithm 
or a statistical multiplexing algorithm. 

A Wide Area Network (WAN) router 408 connects the LAN 
406 to the WAN to facilitate communication between the DACs 
400 and the DPCs 600. In the preferred embodiment, the WAN 

25 router 408 is a CISCO 4700 WAN Router. The WAN router 408 
uses frame relay connectivity to connect the DAC LAN 406 to 
the WAN. As is known to persons of ordinary skill in the 
art, alternate devices, such as the NORTEL Magellen Passport 
"50" Telecommunication Switch, could be used to facilitate 

3 0 communication between the DACs 400 and the DPCs 600 as long 
as the selected router meets the performance and quality 
communication requirements of the system. 

As is known to persons of ordinary skill in the art, 
frame relay is an interface protocol for statistically 

35 multiplexed packet-switched data communications in which 
variable-sized packets (frames) are used that completely 
enclose the user packets which they transport. In contrast 
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to dedicated point to point links that guarantee a specific 
data rate, frame relay communication provides bandwidth on- 
demand with a guaranteed minimum data rate. Frame relay 
communication also allows occasional short high data rate 
5 bursts according to network availability. 

Each frame encloses one user packet and adds addressing 
and verification information. Frame relay data communication 
typically has transmission rates between 56 kilobytes per 
second (kb/s) and 1.544 megabytes per second (Mb/s) . Frames 
10 may vary in length up to a design limit of approximately 1 
kilobyte. 

The Telco Carrier Cloud 412 is a communication network 
which receives the frames destined for the DPC 600 sent by 
the WAN router 408 from the DACs 400. As is known to persons 
15 of ordinary skill in the art, carriers provide communication 
services at local central offices. These central offices 
contain networking facilities and equipment to interconnect 
telephone and data communications to other central offices 
within its own network and within networks of other carriers, 

2 0 Since carriers share the component links of the 

interconnection network, data communication must be 
dynamically assigned to links in the network according to 
availability. Because of the dynamic nature of the data 
routing, the interconnection network is referred to as a 
25 carrier cloud of communication bandwidth. 

All the DAC 400 equipment is on fully redundant on-line 
UPS power supplies to insure maximum power availability. 
Further, to minimize the time for trouble detection, trouble 
analysis and repair, all the DAC 400 equipment incorporates 

3 0 trouble detection and remote reporting/diagnostics as is 

known to an artisan of ordinary skill in the art. 

FIG. 5 is a flow chart 500 describing the polling of the 
DATs 200 by a DAC 400 and the transmission of the TECBIs from 
the DATs 200 to the DAC 400. In step 502, the DAC server 402 
35 reads the address of the first DAT 200 in its region for 
polling. In step 504, a modem in the modem bank 404 dials 
the first DAT 200. The DAC 400 determines whether the call 
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to the' DAT 200 was successful in step 505. If the call to 
the first DAT 200 was unsuccessful, the DAC 400 will record 
the error condition in the session summary report and will 

report the error to the DPC 600 in step 522. ^ . 

5 If the call to the first DAT 200 was successful, the 

DAC 4 00 will verify that the DAT 200 is ready to transmit in 
step 508. If the DAT 200 is not ready to transmit, the DAC 
400 will record the error condition in the session summary 
report and will report the error to the DPC 600 in step 522. 
10 If the DAT 200 is ready to transmit in step 508, the DAT 

200 will transmit a TECBI packet header to the DAC 400 in 
step 510. The DAC 400 will determine whether the 
transmission of the TECBI packet header was successful in 

step 512. If the transmission of the TECBI packet header was ^iti^^liNi^^^^^^^^ 
15 unsuccessful, the DAC 400 will record the error condition in 

the session summary report and will report the error to the 

DPC 600 in step 522. 

If the transmission of the TECBI packet header was 

successful in step 512, the DAT 200 will transmit a TECBI 
20 packet to the DAC 400 in step 514. The DAC 400 will 

determine whether the transmission of the TECBI packet was 

successful in step 516. If the transmission of the TECBI 

packet header was unsuccessful, the DAC 400 will record the 

error condition in the session summary report and will report 
25 the error to the DPC 600 in step 522. 

If the transmission of the TECBI packet was successful 

in step 516, the DAC 400, in step 518, will compare the TECBI 

packet header transmitted in step 510 to the TECBI packet 

transmitted in step 514. If the TECBI packet header does not 
30 match the TECBI packet, the DAC 400 will record the error 

condition in the session summary report and will report the 

error to the DPC 600 in step 522. 

If the TECBI packet header matched the TECBI packet in 

step 518, the DAC 400 will set the status of the TECBI packet 
3 5 to indicate that it is ready for transmission to the DPC 600 

in step 520, The DAC 400 will also transmit the status to 

the DAT 200 to indicate successful completion of the polling 



- 23 - 



PEDC-939S5 3 



and transmission session in step 520. Next, the DAC 400 will 
determine whether TECBIs have been transmitted from all of 
the DATs 200 in its region in step 524. If all DATs 200 in 
the DAC's 400 region have transmitted TECBIs to the DAC 400, 
5 the DAC 4 00 will compile a DAT 2 00 status report in step 528 
before terminating the session. 

If one or more DATs 200 in the DAC's 4 00 region have not 
transmitted TECBIs to the DAC 400, the DAC 400 will get the 
address of the next DAT 200 in the region in step 526. Next, 

10 control returns to step 504 where the next DAT 200 in the 
DAC's 400 region will be polled as previously discussed. 

In the preferred embodiment, the DAC server 402 
initiates the polling and data transmission at optimum toll 
rate times to decrease the cost of data transmission. In 

15 addition to the raid drives and redundant servers, the DAC 
400 will also have dual tape backup units which will 
periodically backup the entire data set. If there is a 
catastrophic failure of the DAC 400 , the tapes can be 
retrieved and sent directly to the DPC 600 for processing. 

20 As the DAT 200 polling and data transmission progresses, the 
DAC 400 will periodically update the DPC 600 with its status. 
If there is a catastrophic failure with the DAC 400, the DPC 
600 would know how much polling and backup has been done by 
the failing DAC 400. Accordingly, the DPC 600 can easily 

25 assign another DAC 400 to complete the polling and data 

transmission for the DATs 200 in the failed DAC's 400 region. 

FIG. 6 is a block diagram of tiie DPC 600 architecture. 
The DPC 600 accumulates, processes and stores images for 
later retrieval by DataTreasury™ System retrieval customers 

3 0 who have authorization to access relevant information - 

DataTreasury™ System retrieval customers include credit card 
merchants, credit card companies, credit information 
companies and consvuners. As shown in FIG. 6 and FIG. 1, the 
DPC 600 polls the DACs 400 and receives TECBIs which have 

35 accumulated in the DACs 400. 

In the preferred embodiment, the DPC server 602 
comprises stand-alone Digital Equipment Corporation (DEC) SMP 
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Alpha '4100 4/566 servers which are connected on a coinition 
network running Windows NT, The DEC Alpha servers manage the 
collection and intermediate storage of images and data which 
are received from the DACs 400 • 
5 In the preferred embodiment, the DPC server 602 also 

comprises EMC 3700 SYMMETRIX CUBE Disk Storage Systems, which 
store the images and data collected and managed by the DEC 
Alpha servers. Like the DAC 400 architecture, the DPC 600 
architecture uses a SYMMETRIX Remote Data Facility (SRDF) , 
10 available from EMC, to enable multiple, physically separate 
data centers housing EMC Storage Systems to maintain 
redundant backups of each other across a Wide Area Network 
(WAN) . 

Like the DAC 400 architecture, the DPC 600 architecture 

15 uses a WEB based paradigm using an enhanced Domain Name 

Services (DNS) , the Microsoft Component Object Model (DCOM) , 
and Windows NT Application Program Interfaces (APIs) to 
facilitate communication and load balancing among the servers 
comprising the DPC server 602 as described above in the 

20 discussion of the DAC 400 architecture. 

The workstation 604 performs operation control and 
system monitoring and management of the DPC 600 network. In 
the preferred embodiment, the workstation 604, available from 
Compaq, is an Intel platform workstation running Microsoft 

25 Windows NT 4.x. The workstation 604 should be able to run 
Microsoft Windows NT 5.x when it becomes available. The 
workstation 604 executes CA Unicenter TNG software to perform 
network system monitoring and management. The workstation 
604 executes SnoBound Imaging software to display and process 

3 0 TECBIs. 

The workstation 604 also performs identification 
verification by comparing signature data retrieved remotely 
by the DATs 200 with signature data stored at the DPC 600. 
In the preferred embodiment, signature verification software, 
35 available from Communications Intelligence Corporation of 
Redwood Shores, California executing on the workstation 604 
performs the identification verification. As is known to 
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persons of ordinary skill in the art, the workstation 604 
could execute other software to perform identification 
verification by comparing biometric data including facial 
scans, fingerprints, retina scans, iris scans and hand 
5 geometry. Thus, the DPC 600 could verify the identity of a 
person who is making a purchase with a credit card by 
comparing the biometric data captured remotely with the 
biometric data stored at the DPC 600. 

As is known to persons of ordinary skill in the art, the 

10 DataTreasury™ System 100 could use workstations with central 
processing units from other integrated circuit vendors as 
long as the chosen workstation has the ability to perform 
standard operations such as fetching instructions, fetching 
data, executing the fetched instructions with the fetched 

15 data and storing results. Similarly, the DataTreasury™ 

System 100 could use alternate windows operating systems and 
network monitoring software as long as the selected software 
can monitor the status of the workstations and links in the 
network and display the determined status to the operator. 

2 0 The Remote Data Entry Gateway 614 and the Remote Off site 

Data Entry Facilities 616 correct errors which occurred 
during data capture by the DAT 2 00. Since the DataTreasury™ 
System 100 partitions the document as described in the 
discussion of the sample receipt of FIG. 3b, the operator at 

25 the Remote Data Entry Gateway 614 or the Remote Offsite Date 
Entry Facilities 616 only needs to correct the portion of the 
document or image snippet which contained the error. 

Partitioning improves system performance, decreases 
system cost and improves system quality. With partitioning, 

30 the DPC Server 602 only sends the portion of the document 
containing the error to the Remote Data Entry Gateway 614 or 
the Remote Offsite Data Entry Facilities 616. Since the 
operator at these data entry locations only sees the portion 
of the document which contained the error, she can quickly 

35 recognize and correct the error- Without partitioning, the 
operator would have to search for the error in the entire 
document. With this inefficient process, the operator would 
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need more time and would be more likely to make a mistake by 
missing the error or making a modification in the wrong 
location. Accordingly, partitioning improves system 
performance and quality by increasing the speed and accuracy 
5 of the error correction process. 

Similarly, partitioning decreases the traffic on the DPC 
LAN 606 and the Telco Carrier Cloud 412 because the DPC 
Server 602 only sends the image snippet containing the error 
to the Remote Offsite Data Entry Facility 616 or the Remote 

10 Data Entry Gateway 614. Accordingly, partitioning decreases 
system cost by reducing the bandwidth requirement on the 
interconnection networks. 

A DPC LAN 606 facilitates communication among the 
devices which are connected to the LAN 606 including the DPC 

15 server 602 and the network workstation 604. In the preferred 
embodiment, the DPC LAN 606 uses a switched lOOBaseT/ lOBaseT 
communication hardware layer protocol like the DAC LAN 406 
discussed earlier. In the preferred embodiment, the DPC LAN 
406 is a high speed 0C2 network topology backbone supporting 

2 0 TCP/IP. The CISCO Catalyst 5500 Network Switch supports the 
DPC LAN 606 connectivity among the devices connected to the 
LAN 606. 

As is known to persons of ordinary skill in the art, 
alternate LAN architectures could be used to facilitate 

25 communication among the devices of the LAN 406. For example, 
the LAN 406 could use a hub architecture with a round robin 
allocation algorithm, a time division multiplexing algorithm 
or a statistical multiplexing algorithm. 

A Wide Area Network (WAN) router 612 connects the DPC 

30 LAN 606 to the WAN to facilitate communication between the 
DACs 400 and the DPCs 600. In the preferred embodiment, the 
WAN router 612 is a CISCO 7507 WAN Router. The WAN router 
612 uses frame relay connectivity to connect the DPC LAN 612 
to the WAN, As is known to persons of ordinary skill in the 

35 art, alternate devices, such as the NORTEL Magellen Passport 
"50" Telecommunication Switch, could be used to facilitate 
communication between the DACs 4 00 and the DPCs 600 as long 
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as the selected router meets the performance and quality 
communication requirements of the system 

The DPC 600 has a three tier storage architecture to 
support the massive storage requirement on the DataTreasury™ 
5 System 100. In the preferred embodiment, the storage 

architecture consists of Fiber Channel RAID technology based 
EMC Symmetrix Enterprise Storage Systems where individual 
cabinets support over 1 Terabyte of storage* After TECBI 
images have been processed and have been on-line for 30 days, 

10 they will be moved to DVD based jukebox systems. After the 
TECBI images have been on-line for 90 days, they will be 
moved to Write Once Read Many (WORM) based jiikebox systems 
608 for longer term storage of up to 3 years in accordance 
with customer requirements. 

15 In an alternate embodiment, the DPC 600 is intended to 

also configure a High Density Read Only Memory (HD-ROM) when 
it becomes available from NORSAM Technologies, Los Alamos, 
New Mexico, into optical storage jukebox systems 610, such as 
that which is available from Hewlett Packard, to replace the 

20 DVD components for increased storage capacity. The HD-ROM 
conforms to CD-ROM form factor metallic WORM disc. The HD- 
ROM currently has a very large storage capacity of over 320 
giga bytes (320 GB) on a single platter and has an 
anticipated capacity of several terabytes (TB) on a single 

25 platter. The DPC 600 uses IBM and Philips technology to read 
from the HD-ROM and to write to the HD-ROM. 

The DPC Alpha servers of the DPC server 602 insert 
images and data received from the DACs 400 into a single 
database which is stored on the Digital Storage Works Systems 

30 using a data manipulation language as is well known to 
persons of ordinary skill in the art. In the preferred 
embodiment, the database is the V8.0 Oracle relational 
database which was designed to support both data and image 
storage within a single repository. 

35 As known to persons of ordinary skill in the art, a 

relational database consists of a collection of tables which 
have a unique name. See, e.g.. Chapter Three of Database 
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System Concepts by Korth and Silberschatz . A database schema 
is the logical design of the database. Each table in a 
relational database has attributes, A row in a table 
represents a relationship among a set of values for the 
5 attributes in the table. Each table has one or more 

superkeys. A superkey "is a set of one or more attributes 
which uniquely identify a row in the table. A candidate key 
is a superkey for which no proper subset is also a superkey. 
A primary key is a candidate key selected by the database 

10 designer as the means to identify a row in a table. 

As is well known to persons of ordinary skill in the 
art, the DataTreasury™ System 100 could use other database 
models available from other vendors including the entity 
relationship model as long as the selected database meets the 

15 storage and access efficiency requirements of the system. 

See, e.g., Chapter 2 of Database System Concepts by Korth and 
Silberschatz . 

An exemplary DPC 600 basic schema consists of the tables 
listed below. Since the names of the attributes are 

20 descriptive, they adequately define the attributes' contents. 
The primary keys in each table are identified with two 
asterisks (**) . Niimeric attributes which are unique for a 
particular value of a primary key are denoted with the 
suffix, "NO". Numeric attributes which are unique within the 

25 entire relational database are denoted with the suffix, 
"NUM" . 

I. CUSTOMER: This table describes the DataTreasury"* System 





customer . 


30 


A. 


**CUSTOMER_ID 




B. 


COMPANY__NAME 




C. 


CONTACT 




D. 


CONTACT_TITLE 




E. 


ADDRl 


35 


F. 


ADDR2 




G. 


CITY 




H. 


STATE CODE 
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ZIP_CODE 
J. COUNTRY_CODE 
K. VOX_PHONE 
L. FAX_PHONE 
M . CREATE_DATE 

II. CUSTOMER_MAIL_TO : This table describes the. mailing 
address of the DataTreasury™ System customer. 





A. 


**MAIL_TO_NO 


10 


B, 


**CUST__ID 




C. 


CUSTOMER_NAME 




D. 


CONTACT 




E. 


CONTACT_TILE 




F. 


ADDRl 


15 


G. 


ADDR2 




H. 


CITY 




I. 


STATE__CODE 




J. 


ZIP_CODE 




K, 


COUNTRY_CODE 


20 


L. 


VOX_PHONE 




M. 


FAX_PHONE 




N, 


CREATE_DATE 




O. 


COMMENTS 



25 III. CUSTOMER_DAT_SITE: This table describes the DAT 
location of the DataTreasury"** System customer. 



35 



A. 


**DAT_SITE_NO 


B. 


**CUST_ID 


C. 


CUSTOMER_NAME 


D. 


CONTACT 


E. 


C0NTACT_TILE 


F. 


ADDRl 


G. 


ADDR2 


H. 


CITY 


I. 


STATE_CODE 


J. 


ZIP_CODE 


K. 


COUNTRY CODE 
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L. VOX_PHONE 
M. FAX_PHONE 
N . CREATE_DATE 

O. COMMENTS ' ^ 

5 

IV. CUSTOMER_SITE_DAT:' This table describes the DAT site(s) 
of the DataTreasury™ System customer • 

A. **DAT_TERMINAL_ID 

B . **DAT__SITE_NO 
XO C. **CUST_ID 

D, INSTALL_DATE 

E* LAST_SERVICE_DATE 

F. CREATE DATE 

G. COMMENTS • 

15 

V. DATA_SPEC: This table provides data specifications for 
document partitioning and extraction. 

A . * *DATA_SPEC_ID 

**CUST_ID 
20 C. DESCR 

D. RECORD_LAYOUT_RULES 
E • CREATE_DATE 
F . COMMENTS 

25 VI. DATA_SPEC_FIELD: This table provides field data 

specifications for dociiment partitioning and extraction • 



30 



35 



A. 


**DATA_SPEC_NO 


B. 


**DATA_SPEC_ID 


C. 


FIELD_NAME 


D. 


DESCR 


E. 


DATA_TYPE 


F. 


VALUE_MAX 


G. 


VALUE__MIN 


H. 


START_POS 


I. 


END_POS 


J. 


FIELD_LENGTH 


K. 


RtTLES 
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Li CREATE__DATE 
M. COMMENTS 

VII. TEMPL_DOC: This table specifies the partitioning of a 
5 predefined document. 

A . * *TEMPL_DOC_NUM 

B. DATA_SPEC_ID 

C. DESCR 

D . RULES 

10 E. CREATE_DATE 

F. COMMENTS 

VIII. TEMPL FORM: This table defines the location of forms on 
a predefined document. 

15 



20 



25 



30 



35 



A. 


* *TEMPL_FORM_NO 


B. 


* *TEMPL_DOC_NUM 


c. 


SIDES_PER_F0RM 


D. 


MASTER_IMAGE_SIDE__A 


E. 


MASTER_IMAGE__S I DE_B 


F. 


DI SPLAY_ROTATION_A 


G. 


DISPLAY_ROTATION_B 


H. 


DESCR 


I. 


RULES 


J. 


CREATE_DATE 



IX. TEMPL^PANEL: This table specifies the location of panels 
within the forms of a predefined dociiment. 



A, 


* * TEMPL_PANEL__NO 


B. 


**TEMPL_SIDE_NO 


c. 


* *TEMPL_FORM_NO 


D. 


* *TEMPL_DOC_NUM 


E. 


DISPLAY_ROTATION 


F. 


PANEL_UL_X 


G. 


PANEL_UL_Y 


H. 


PANEL_LR_X 


I. 


PANEL_LR_Y 


J. 


DESCR 
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K. RULES 

L. CREATE DATE 



X. TEMPIj_FIELD: This table defines the location of fields 
5 within the panels of a form of a predefined document. 



10 



15 



A. 


**TEMPL_FIELD_NO 


B, 


* *TEMPI,_PANEL_NO 


C. 


* *TEMPIi__S IDE_NO 


D. 


* *TEMPL_FORM_NO 


E. 


* *TEMPL_DOC_NUM 




DISPLAY_ROTATION 


G. 


FLD_UL_X 


H. 


FLD__UL_Y 


I. 


FLD_LR_X 


J- 


FIiD__LR_Y 


K. 


DESCR 


L. 


RULES 


M. 


CREATE_DATE 



20 XI. DAT__BATCH: This table defines batches of docaiments which 

vere processed during a DAT session. 

A. **DAT_BATCH_NO 

B . * *DAT_SESSION_NO 

C. **DAT_SESSION_DATE 
25 D. **DAT_TERMINAL__ID 

E. DAT__UNIT_CNT 

F. CREATE_DATE 

XII* DAT_UNIT: This table defines the unit in a batch of 
30 documents which were processed in a DAT session. 

A . * *DAT_UNIT_NUM 

B . * *DAT_BATCH_NO 

C. **DAT_SESSION_NO 

D. **DAT_SESSION_DATE . . 
35 E. **DAT_TERMINAL_ID 

F, FORM_CNT 

G. DOC_CNT 
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H, CREATE_DATE 

XIII. DAT_DOC: This table defines dociiments in the unit of 

documents which were processed in a DAT session. 
5 A. **DAT_DOC_NO 

B . * *DAT_UNIT_NUM 

C . DOC__RECORD_DATA 

D. CREATE DATE 



10 The DATA_SPEC, DATA__SPEC_FIELD , TEMPL__DOC, TEMPL_FORM, 

TEMPL_PANEL and TEMPL_FIELD tables implement the doctment 
partitioning algorithm mentioned above in the discussion of 
the sample receipt of FIG. 3b. The cross product of the 

DATA_SPEC and DATA_SPEC__FIELD tables partition arbitrary ^ - 

15 documents while the cross product of the TEMPL_DOC, 

TEMPL_FORM, TEMPL_PANEL and TEMPL_FIELD tables partition 

predefined documents of the DataTreasury™ System 100. The 

TEMPL-FORM defines the location of forms on a predefined 

document. The TEMPL-PANEL defines the location of panels 
2 0 within the forms of a predefined document. Finally, the 

TEMPL_FIELD table defines the location of fields within the 

panels of a form of a predefined document. 

The DPC 600 performs data mining and report generation 

for a wide variety of applications by returning information 
2 5 from the data base. For example, the DPC 600 generates 

market trend analysis reports and inventory reports for 

merchants by analyzing the data from receipts captured by the . 

DAT 200. The DPC 600 also can provide important tax 

information to the taxpayer in the form of a report or to 
30 software applications like tax preparation software by 

retrieving tax information from the database which originally 

resided on receipts, documents and electronic transactions 

captured by the DAT 200. Similarly, the DPC 600 can also 

provide tax information for particular periods of time for a 
35 tax audit. w;;, • 

FIG. 7 is a flow chart 700 describing the polling of the 

DACs 3 00 by a DPC 600 and the transmission of the TECBIs from 
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the DACs 300 to the DPC 600. In step 702, the DPC 600 reads 
the address of the first DAC 300 in its region for polling. 
In step 704, the DPC 600 connects with a DAC 300 for 
transmission. The DPC 600 determines whether the connection 
5 to the DAC 300 was successful in step 706. If the call to 
the DAC 300 was unsuccessful, the DPC 600 will record the 
error condition in the session sximmary report and will report 
the error to the DPC 600 manager in step 722. 

If the connection to the DAC 300 was successful, the DPC 

10 600 will verify that the DAC 3 00 is ready to transmit in step 
708. If the DAC 300 is not ready to transmit, the DPC 600 
will record the error condition in the session summary report 
and will report the error to the DPC 600 manager in step 722. 
If the DAC 300 is ready to transmit in step 708, the DAC 

15 3 00 will transmit a TECBI packet header to the DPC 600 in 
step 710. The DPC 600 will determine whether the 
transmission of the TECBI packet header was successful in 
step 712- If the transmission of the TECBI packet header was 
unsuccessful, the DPC 600 will record the error condition in 

2 0 the session summary report and will report the error to the 

DPC 600 manager in step 722. 

If the transmission of the TECBI packet header was 
successful in step 712, the DAC 300 will transmit a TECBI 
packet to the DPC 600 in step 714. The DPC 600 will 
25 determine whether the transmission of the TECBI packet was 
successful in step 716. If the transmission of the TECBI 
packet header was unsuccessful, the DPC 600 will record the 
error condition in the session summary report and will report 
the error to the DPC 600 manager in step 722, 

3 0 If the transmission of the TECBI packet was successful 

in step 716, the DPC 600, in step 718, will compare the TECBI 
packet header transmitted in step 710 to the TECBI packet 
transmitted in step 714. If the TECBI packet header does not 
match the TECBI packet, the DPC 600 will record the error 
35 condition in the session summary report and will report the 
error to the DPC 600 manager in step 722. 
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If the TECBI packet header matched the TECBI packet in 
step 718, the DPC 600 will set the status of the TECBI packet 
to indicate that it was received at the DPC 600 in step 720. 
The DPC 600 will also transmit the status to the DAC 300 to 
5 indicate successful completion of the polling and 

transmission session in step 720. Next, the DPC 600 will 
determine whether TECBIs have been transmitted from all of 
the DACs 300 in its region in step 724. If all DACs 300 in 
the DPC's 600 region have transmitted TECBIs to the DPC 600, 
10 the DPC 600 will compile a DAC 300 status report in step 728 
before terminating the session. 

If one or more DACs 300 in the DPC's 600 region have not 
transmitted TECBIs to the DPC 600, the DPC 600 will get the 
address of the next DAC 300 in the region in step 726. Next, 
15 control returns to step 704 where the next DAC 3 00 in the 
DPC's 600 region will be polled as previously discussed. 

FIG. 8 is a flow chart 800 describing the data 
processing performed by the DPC 600. In step 802, the DPC 
600 fetches the first TECBI packet. Next, the DPC 600 
20 extracts the first TECBI from the TECBI packet in step 804. 
In step 806, the DPC 600 inserts the TECBI into the database. 
In step 808, the DPC 600 extracts the tag header which 
includes the customer identifier, the encryption keys and the 
template identifier from the TECBI to obtain the ECBI. 
25 In step 810, the DPC 600 decrypts the ECBI image to 

obtain the CBI. In step 812, the DPC 600 uncompresses the 
CBI to obtain the BI. In step 814, the DPC 600 fetches and 
applies the BI template against the BI. Further the DPC 600 
divides the BI into image snippets and tags the BI template 
30 with data capture rules in step 814 to form the Tagged Bitmap 
Image Snippets (TBIS) . In step 816, the DPC 600 submits the 
TBISs for data capture operations to form the IS Derived Data 
Record (ISDATA) . The DPC 600 discards the TBISs upon 
completion of the data capture operations in step 816. In 
35 Step 818, the DPC 600 updates the TECBI record in the 
database with the IS Derived Data. 
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In step 820, the DPC 600 determines whether it has 
processed the last TECBI in the TECBI packet. If the last 
TECBI in the TECBI packet has not been processed, the DPC 600 
extracts the next TECBI from the TECBI packet in step 822. 
5 Next, control returns to step 806 where the next TECBI will 
be processed as described above. 

If the last TECBI in the TECBI packet has been 
processed, the DPC 600 determines whether the last TECBI 
packet has been processed in step 824. If the last TECBI 
10 packet has not been processed, the DPC 600 fetches the next 
TECBI packet in step 826. Next, control returns to step 804 
where the next TECBI packet will be processed as described 
above. If the last TECBI packet has been processed in step 
824, the DPC 600 terminates data processing, 
15 As is known to persons of ordinary skill in the art, a 

user can request information from a relational database using 
a query language. See, e.g., Chapter Three of Database 
System Concepts by Korth and Silberschatz , For example, a 
user can retrieve all rows of a database table having a 
20 primary key with particular values by specifying the desired 
primary key's values and the table name on a select 
operation. Similarly, a user can retrieve all rows from 
multiple database tables having primary keys with particular 
values by specifying the desired primary keys' values and the 
25 tables with a select operation. 

The DataTreasury™ System provides a simplified interface 
to its retrieval customers to enable data extraction from its 
relational database as described in FIG. 9. For example, a 
DataTreasury™ System customer can retrieve the time, date, 
30 location and amount of a specified transaction. 

The DPC 600 performs data mining and report generation 
for a wide variety of applications by returning information 
from the data base. For example, the DPC 600 generates 
market trend analysis reports and inventory reports for 
35 merchants by analyzing the data from receipts captured by the 
DAT 200, The DPC 600 also can provide important tax 
information to the taxpayer in the form of a report or to tax 
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preparation software by retrieving tax information from the 
database which originally resided on receipts, documents and 
electronic transactions captured by the DAT 200. Similarly, 
the DPC 600 can also provide tax information for particular 
5 periods of time for a tax audit. 

FIG. 9 is a flowchart 900 describing the data retrieval 
performed by the DPC 600. In step 902, the DPC 600 receives 
a TECBI retrieval request. In step 904, the DPC 600 obtains 
the customer identifier. In step 906, the DPC 600 determines 
10 whether the customer identifier is valid. If the customer 
identifier is not valid, control returns to step 904 where 
the DPC 600 will obtain another customer identifier. 

If the customer identifier is valid in step 906, the DPC 
600 will obtain the customer security profile in step 908. 
15 In step 910, the DPC 600 receives a customer retrieval 
request. In step 912, the DPC 600 determines whether the 
customer retrieval request is consistent with the customer 
security profile. If the customer retrieval request is not 
consistent with the customer security profile, control 
20 returns to step 910 where the DPC 600 will obtain another 
customer retrieval request. If the customer retrieval 
request is consistent with the customer security profile, the 
DPC 600 will transmit the results to the customer as 
indicated by the customer security profile in step 914, 
25 FIG. 10 is a flow chart describing the use of the 

DataTreasury™ system to process checks. In step 1004, the 
DataTreasury"* system captures the check at the payer's remote 
location in the preferred embodiment before the payer 
presents the check to the payee. Alternatively, the payer 
30 simply presents or mails the check to the payee. The capture 
of the check at the payer's remote location in step 1004 
enables subsequent comparison of the check as written by the 
payer with the check as received by the payee. In other 
words, this step enables the detection of check alteration 
35 from fraudulent check schemes where a check is intercepted 
before receipt by the payee and chemically washed to allow 
the perpetrator to work with a blank check. 
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In step 1006, the DataTreasury™ system captures the 
check and the payer's biometric data at the payee's remote 
location. In an alternate embodiment, the DataTreasury"* 
system sends electronic transaction data representing the 
5 check from the payer's remote location to the payer's remote 
location. In step 1008, the DataTreasury™ system performs 
verification of the check and biometric data by comparing the 
remotely captured data with the data stored at a central 
location. The validation further includes checking the 

10 courtesy amount and the payer's signature. 

In step 1010, the DataTreasury™ system determines 
whether the verification was successful. If the verification 
of step 1010 was not successful, the system transmits an 
error message to the remote locations in step 1012 and 

15 returns to step 1004 for resubmission. If the verification 
of step 1010 was successful, the system creates an electronic 
transaction representing the check at a central location in 
step 1014. The electronic transaction representing the check 
consists of the payer bank's identification number, routing 

2 0 information, the payer's account number, a payer's check, a 

payer bank's draft, the amount of the check or draft, the 
payee bank's identification number, the payee bank's routing 
information, and the payee's account number. In step 1016, 
the electronic transaction representing the check is 
25 transmitted to the payee bank. In step 1018, the payee bank 
transmits the electronic transaction representing the check 
to the payer bank. 

In step 1020, the payer bank verifies the electronic 
transaction representing the check and determines whether to 

3 0 approve a fund transfer. If the payee bank grants approval 

in step 1020, the payer bank transfers the funds from the 
payer bank to the payee bank in step 1022. In step 1024, the 
DataTreasury™ system notifies the payee bank and the remote 
locations as to the status of the transfer. 
35 While the above invention has been described with 

reference to certain preferred embodiments, the scope of the 
present invention is not limited to these embodiments. One 
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skilled in the art may find variations of these preferred 
embodiments which, nevertheless, fall within the spirit of 
the present invention, whose scope is defined by the claims 
set forth below. 
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THE CLAIMS 



What is claimed is: 

5 1. A system for central management^ storage and report 

generation of remotely captured paper transactions from 
documents and receipts comprising: 

one or more remote data access subsystems for capturing 
and sending paper transaction data comprising at least one 
10 data access controller for managing the capturing and sending 
of the transaction data; 

at least one central data processing subsystem for 
processing, sending, verifying and storing the paper 
transaction data comprising a data management subsystem for 
15 managing the processing, sending and storing of the 
transaction data; and 

at least one communication network for the transmission 
of the transaction data within and between said one or more 
data access subsystems and said at least one data processing 
20 subsystem. 

2, A system as in claim 1 wherein said one or more data 
access subsystems further comprise at least one scanner for 
capturing the paper transaction data. 

25 

3 . A system as in claim 2 wherein said one or more 
data access subsystems also capture electronic transactions 
from credit cards, smart cards and debit cards, signature 
data or biometric data, further comprising: 

30 at least one card interface for capturing the electronic 

transaction data; 

at least one signature interface for capturing an 
electronic signature; and 

at least one biometric interface for capturing biometric 



35 data. 
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4 • A system as in claim 3 wherein said at least one 
data access controller successively transforms the captured 
transaction data to a bitmap image, a compressed bitmap 
image, an encrypted, compressed bitmap image and an 
5 encrypted, compressed bitmap image tagged with information 
identifying a location 'and time of the transaction data 
capture • 

5. A system as in claim 4 wherein said one or more data 
10 access subsystems further comprise digital storage for 

storing the tagged, encrypted, compressed bitmap image. 

6. A system as in claim 5 wherein said at least one 
card interface initiates the electronic transaction. 

15 

7. A system as in claim 6 wherein said one or more data 
access subsystems further comprise at least one printer for 
printing the paper transaction initiated by said at least one 
card interface. 



8- A system as in claim 7 wherein the paper transaction 
printed by said at least one printer includes data glyphs. 

9. A system as in claim 1 wherein said data management 
25 subsystem of said at least one data processing subsystem 
comprises: 

at least one server for polling said one or more remote 
data access subsystems for transaction data; 

a database subsystem for storing the transaction data in 
30 a useful form; 

a report generator for generating reports from the 
transaction data and providing data to software applications; 

at least one central processing unit for managing the 
storing of the transaction data; 
35 a domain name services program for dynamically assigning 

one of said at least one server to receive portions of the 
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transaction data for balancing the transaction data among 
said at least one server; and 
a memory hierarchy. 

10. A system as in claim 9 wherein said at least one 
server also polls for biometric and signature data, said 
database stores the biometric data and the signature data, 
and said at least one central processing unit verifies the 
biometric data and the signature data. 

11. A system as in claim 9 wherein said memory 
hierarchy comprises at least one primary memory for storage 
of recently accessed transaction data and at least one 
secondary memory for storage of other transaction data. 

12. A system as in claim 11 wherein said at least one 
secondary memory comprises at least one write once read many 
jxikebox and at least one optical storage jukebox. 

13. A system as in claim 12 wherein said at least one 
optical storage jukebox comprises read only memory technology 
including compact disc read only memory form factor metallic 
write once read many disc. 

14. A system as in claim 9 wherein said database 
subsystem comprises at least one predefined template for 
partitioning the stored transaction data into panels and 
identifying locations of the panels, 

I 15. A system as in claim 14 wherein said data 

processing subsystem further comprises a data entry gateway 
for correcting errors in the panels of stored transaction 
data. 

► 16. A system as in claim 1 wherein said at least one 

communication network comprises: 
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at least one first local area network for transmitting 
data within a corresponding one of said one or more remote 
data access subsystems; 

at least one second local area network for transmitting 
5 data within a corresponding one of said at least one data 
processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access subsystems and 
said at least one data processing subsystem. 

10 

17. A system as in claim 16 wherein said at least one 
communication network further comprises: 

at least one modem for connecting said at least one 
first local area network of said one or more data access 

15 subsystems to a corresponding one of said at least one second 
local area network of said at least one data processing 
subsystem through said at least one wide area network; and 

at least one bank of modems for connecting said at least 
one second local area network of said at least one data 

2 0 processing subsystem to a corresponding some of said at least 
one first local area network of said one or more data access 
subsystems through said at least one wide area network. 

18. A system as in claim 1 further comprising at least 
25 one data collecting subsystem for collecting and sending the 

electronic or paper transaction data comprising a further 
management subsystem for managing the collecting and sending 
of the transaction data. 



30 19 . A system as in claim 18 wherein said further data 

management subsystem of said at least one data collecting 

subsystem comprises; 

at least one server for polling said one or more remote 

data access subsystems for transaction data; ..^ „ 

35 a database for storing the transaction data in a useful 

form; 
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at least one central processing unit for managing the 
collecting of the transaction data; 

a domain name services program for dynamically assigning 
one of said at least one server to receive portions of the 
5 transaction data for balancing the transaction data among 
said at least one server; and 

a memory hierarchy. 

20. A system as in claim 19 wherein said memory 
10 hierarchy comprises at least one primary memory for 

collecting transaction data and at least one secondary memory 
for backup storage of the transaction data. 

21. A system as in claim 20 wherein said at least one 
15 secondary memory comprises at least one DLT jukebox - 

22. A system as in claim 18 wherein said at least one 
conmiunication network comprises: 

at least one first local area network for transmitting 
20 data within a corresponding one of said one or more remote 
data access subsystems; 

at least one second local area network for transmitting 
data within a corresponding one of said at least one data 
collection subsystem; 
25 at least one third local area network for transmitting 

data within a corresponding one of said at least one data 
processing subsystem; and 

at least one wide area network for transmitting data 
between said one or more remote data access subsystems, said 
30 at least one data collection subsystem and said at least one 
data processing subsystem. 

23. A system as in claim 22 wherein said at least one 
communication network further comprises: 

35 at least one first modem for connecting said at least 

one first local area network of said one or more data access 
subsystems to a corresponding one of said at least one second 
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local- area network through said at least one wide area 
network ; 

at least one bank of modems for connecting said at least 
one second local area network of said at least one data 
5 collection subsystem to a corresponding some of said at least 
one first local area network of said one or more data access 
subsystems through said at least one wide area network; 

at least one first wide area network router for 
connecting a corresponding one of said at least one second 
10 local area network of said at least one data collecting 
subsystem to said at least one wide area network; and 
at least one second wide area network router for 
connecting a corresponding one of said at least one third 
local area network of said at least one data processing 
15 subsystem to said at least one wide area network. 

24. A system as in claim 23 wherein said at least one 
first wide area network and said at least one second wide 
area network comprises a carrier cloud, said carrier cloud 

2 0 using a frame relay method for transmitting the transaction 
data. 

25. A system as in claim 22 wherein said at least one 
second local area network and said at least one third local 

25 area network further comprises a corresponding one of at 

least one network switch for routing transaction data within 
said at least one second local area network and said at least 
one third local area network - 

30 26. A method for central management, storage and 

verification of remotely captured paper transactions from 
documents and receipts comprising the steps of: 

capturing and sending the paper transaction data at one 
or more remote locations; 

35 managing the capturing and sending of the transaction 

data ; 
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collecting, processing, sending and storing the 
transaction data at a central locations- 
managing the collecting, processing, sending and storing 
of the transaction data; and 
5 transmitting the transaction data within and between the 

remote location (s) and the central location, 

27. The method as in claim 26 wherein said managing the 
capturing and sending step comprises the steps of: 

10 successively transforming the captured transaction data 

to a bitmap image, a compressed bitmap image, an encrypted, 
compressed bitmap image and an encrypted, compressed bitmap 
image tagged with information identifying a location and time 

of the transaction data capturing; and ^3r#1i??1fS?^^^^^ 
15 storing the tagged, encrypted, compressed bitmap image, 

28. The method as in claim 27 wherein said managing the 
capturing and sending step also captures electronic 
transactions from credit cards, smart cards and debit cards, 

2 0 signature data or biometric data, further comprising the ^^mms^m'^ 
steps of: 

initiating an electronic transaction; 
capturing signature data; 
capturing biometric data; and 

2 5 printing a paper transaction with data glyphs for the 

initiated electronic transaction, 

29. A method as in claim 26 wherein: 

said capturing and sending step occurs at a plurality of 

3 0 remote locations; and 

said collecting, processing, sending and storing step 
occurs at a plurality of central locations, 

30. A method as in claim 29 wherein said collecting, 
35 processing, sending and storing step comprises the steps of: 

polling the remote locations for transaction data with 
servers at the central locations; 
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storing the transaction data at the central location in 
a meiaory hierarchy, said storing maintains recently accessed 
transaction data in a primary memory and other transaction 
data in a secondary memory; and 
5 dynamically assigning the servers at the central 

location to receive portions of the transaction data for 
balancing the transaction data among the servers; and 

generating reports from the transaction data and 
providing data to software applications* 

10 

31. A method as in claim 30 wherein said storing the 
transaction data step comprises the steps of: 

partitioning the stored transaction data with predefined 
templates into panels; and 
15 identifying locations of the panels. 

32. A method as in claim 31 wherein said managing the 
collecting, processing, sending and storing of the 
transaction data step comprises correcting errors in the 

20 panels of stored transaction data. 

33. A method as in claim 32 further comprising the 
steps of: 

polling the remote locations for captured electronic 
25 data, captured signature data and captured biometric data 
with servers at the central locations; and 

comparing the captured signature data and the captured 
biometric data to stored signature data and stored biometric 
data respectively for identification verification. 

30 

34. A method as in claim 32 wherein said transmitting 
the transaction data step comprises the steps of: 

transmitting data within the remote locations; 
transmitting data from each remote location to a 
35 corresponding central location; and 

transmitting data within the central locations. 
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35, A method as in claiia 34 wherein said transmitting 
data from each remote location to a corresponding central 
location step comprises the steps of: 

connecting each remote location to a corresponding 
5 central location; and 

connecting each central location to corresponding remote 

locations . 

36, A method as in claim 29 further comprising the 
10 steps of: 

collecting and sending the electronic or paper 
transaction data at intermediate locations; 

managing the collecting and sending of the transaction 
data ; and 

15 transmitting the transaction data within the 

intermediate location and between the intermediate locations 
and the remote locations and the central locations. 

37. A method as in claim 36 wherein said managing the 
20 collecting and sending step comprises the steps of: 

polling the remote locations for transaction data with 
servers in the intermediate locations; 

storing the transaction data in the intermediate 
locations in a useful form, said storing maintains the 
25 transaction data in a primary memory of a memory hierarchy 
and performs backup storage of the transaction data into a 
secondary memory of the memory hierarchy; and 

dynamically assigning the servers to receive portions of 
the transaction data for balancing the transaction data among 
3 0 the servers - 

38. The method as in claim 36 wherein said transmitting 
the transaction data step comprises the steps of: 

transmitting data within the remote locations; 
35 transmitting data from each remote location to a 

corresponding intermediate location; 

transmitting data within the intermediate locations; 
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transmitting data from each intermediate location to 
corresponding central locations; and 

transmitting data within the central locations, 

5 39. A method as in claim 38 wherein said transmitting 

data from each remote location to corresponding intermediate 
locations step comprises the steps of: 

connecting each remote location to a corresponding 
intermediate location; and 
10 connecting the intermediate locations to corresponding 

remote locations. 

40. A method as in claim 38 wherein said transmitting 
data from each intermediate location to corresponding central 

15 locations comprises the steps of: 

connecting each intermediate location to an external 
communication network; and 

connecting the corresponding central locations to the 
communication network. 

41. A method as in claim 4 0 wherein said transmitting 
data from each intermediate location to corresponding central 
locations step further comprises the steps of: 

packaging the transaction data into frames; and 
25 transmitting the frames through the external 

communication network. 

42. A communication network for the transmission of 
data within and between one or more remote subsystems, at 

3 0 least one intermediate subsystem and at least one central 
subsystem forming a tiered architecture wherein each of said 
at least one central data processing subsystem communicate 
with a corresponding some of said at least one data 
collecting subsystem and each of said at least one data 

35 collecting subsystem communicate with a corresponding some of 
said one or more data processing subsystems comprising: 
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at least one first local area network for transmitting 
data within a corresponding one of said one or more remote 
subsystems ; 

at least one second local area network for transmitting 
5 data within a corresponding one of said at least one 
intermediate subsystem; 

at least one third local area network for transmitting 
data within a corresponding one of said at least one central 
subsystem ; and 

10 at least one wide area network for transmitting data 

between said one or more remote subsystems, said at least one 
intermediate subsystem and said at least one central 
subsystem. 

15 43. A communication network as in claim 42 further 

comprising: 

at least one first modem for connecting said at least 
one first local area network of said one or more remote 
subsystems to a corresponding one of said at least one second 
2 0 local area network through said at least one wide area 
network ; 

at least one bank of modems for connecting said at least 
one second local area network of said at least one 
intermediate subsystem to a corresponding some of said at 
25 least one first local area network of said one or more remote 
subsystems through said at least one wide area network; 

at least one first wide area network router for 
connecting a corresponding one of said at least one second 
local area network of said at least one intermediate 
30 subsystem to said at least one wide area network; and 
at least one second wide area network router for 
connecting a corresponding one of said at least one third 
local area network of said at least one central subsystem to 
said at least one wide area network, 

35 

44. A system as in claim 43 wherein said at least one 
first wide area network and said at least one second wide 
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area network comprises a carrier cloud which utilizes a frame 
relay method for transmitting the transaction data. 



45. A system as in claim 44 wherein said at least one 
5 second local area network and said at least one third local 

area network further comprises a corresponding one of at 
least one network switch for routing transaction data within 
said at least one second local area network and said at least 
one third local area network; and further wherein said data 
10 comprises (a) electronic transactions from credit cards, 
smart cards and debit cards, signature data or biometric 
data, or (b) paper transactions from dociments and receipts. 

46, A method for transmitting data within and between 
15 one or more remote subsystems, at least one intermediate 

subsystem and at least one central subsystem in a tiered 
manner wherein each of the central subsystems communicate 
with a corresponding some of the intermediate subsystems and 
each of the intermediate subsystems communicate with a 
2 0 corresponding some of the remote subsystems comprising the 
steps of: 

transmitting data within the remote locations; 

transmitting data from each remote location to a 
corresponding intermediate location; 
25 transmitting data within the intermediate locations; 

transmitting data from each intermediate location to 
corresponding central locations; and 

transmitting data within the central locations. 

30 47. A method as in claim 46 wherein said transmitting 

data from each remote location to corresponding intermediate 

locations step comprises the steps of : 

connecting each remote location to a corresponding 

intermediate location; and 
35 connecting the intermediate locations to corresponding 

remote locations. 
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48. A method as in claim 47 wherein said transmitting 
data from each intermediate location to corresponding central 
locations comprises the steps of : 

connecting each intermediate location to an external 
5 communication network; and 

connecting the corresponding central locations to the 
external communication network. 

49. A method as in claim 48 wherein said transmitting 
10 data from each intermediate location to corresponding central 

locations step further comprises the steps of: 

packaging the transaction data into frames; and 
transmitting the frames through the external 

communication network. 

15 

50. A method as in claim 46 wherein said data is 
obtained from (a) electronic transactions from credit cards, 
smart cards and debit cards, signature data or biometric 
data, or (b) paper transactions from documents and receipts. 

20 

51. A method for central management, storage and 
verification of remotely captured paper transactions from 
documents and receipts as in claim 33 wherein said comparing 
step further comprises the step of comparing said captured 

25 electronic data to stored electronic data. 

52. A method for central management, storage and 
verification of remotely captured paper transactions from 
documents and receipts as in claim 51 wherein said 

30 transaction data comprises a payer bank's identification 

number, a payer bank's routing number, a payer bank's routing 
information, a payer's account number, a payer's check, a 
payer bank's draft, a check amount, a payee bank's 
identification number, a payee bank's routing information, 

35 and a payee's account number. 
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53. A method for central management, storage and 
verification of remotely captured paper transactions from 
documents and receipts as in claim 52 wherein said managing 
the collecting, processing, sending and storing step further 
5 comprises the step of performing said paper transaction by 
transferring funds electronically from a payer bank to a 
payee bank. 



10 
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REMOTE IMAGE CAPTURE 
WITH CENTRALIZED PROCESSING AND STORAGE 

ABSTRACT 

A system for remote data acquisition and centralized 
processing and storage is disclosed called the DataTreasury™ 
System. The DataTreasury™ System provides comprehensive 
support for the processing of documents and electronic data 
associated with different applications including sale, 
business, banking and general consiimer transactions. The 
system retrieves transaction data such as credit card 
receipts checks in either electronic or paper form at one or 
more remote locations, encrypts the data, transmits the 
encrypted data to a central location, transforms the data to 
a usable form, performs identification verification using 
signature data and biometric data, generates informative 
reports from the data and transmits the informative reports 
to the remote location ( s) . The DataTreasury"* System has many 
advantageous features which work together to provide high 
performance, security, reliability, fault tolerance and low 
cost. First, the network architecture facilitates secure 
communication between the remote location (s) and the central 
processing facility. A dynamic address assignment algorithm 
performs load balancing among the system's servers for faster 
performance and higher utilization. Finally, a partitioning 
scheme improves the error correction process. 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application is a continuation-in-part of 
application serial no. 08/917,761 filed August 27, 1997, 



- 55 - 



PEDC-9 3 9fi5 




Fig. 1 




Fig. 3a 




OmCE DEPOT 
2110 BROAD HOliOW ROAD 
FARMINGDAIE, NY 11735 
51^644^3444 




75608700053 BUSINESS PU\N PRO 
MFG.UST $95.00 

'"txISsKIstI 
tCtal ■ 



A(^UNJNyMBER. 

visA 

"CHANGE 



.??8?888877775^.. 
97.41 

aoo" 



- XEROX DATAGLYPH 




Wmm FOR SHOPPING AND SAVING AT 
OFBCE DEPOT 



Fig. 3b 



START 



i 




720 



/-728 



END 

FIG. y 




Fig. 8 



1004- 



1006- 



CAPTURE CHECKAT 
PAYOR'S REMOTE LOCATION 



CAPTURE CHECKAND 
PAYOR'S BIOMETRIC DATA 
AT PAYEE REMOTE LOCATION 




CREATE ELECTRONIC 
TRANSACTION 




VERIFY XnOTOK 



^TRANSACTION/— — 






T OK 




1024 


TRANSFER 




NOTIFICATION 


-A 


FUNDS 







END. 



Fig. 10 



PENNIE & EDMONDS tu DOCKET NO, 2269-OCr. 

DECLARATION 
AN1> POWER OF ArrOJtNEV 

As a below named inventor^ I hereby declare that: 

My residence, post office address and cicizcnship arc as stated below at 201 et seq. underneath my name. 

r believe I am the original, first and sole inventor if only one name is hsied at 201 below^ or an original, first and joint inventor if plural name, 
are (isted at 201 et seq. below, of ilie subject raatwr which is claimed and for which a patent is sought on the inventxoji entitled 

REMOTE XMAG£ CAPTUBS WITH CENTRAUZED PROCESSING AND STORAGE 

and for which % patent appUcaiioa is attached hereto. 

I hereby state that X have reviewed and underscand che contents of the above identified appHcation, Including the claims, as amended by an^ 
amendment referred to above. 

I aclcnowledge the du^ to disclose iitfannaiion known to me to be material to patentability as defined in Tide 37, Code of Federal Regulations 
§L56. 

X hereby claim foreign priority benefits under Title 35, United Stares Code, §119<aK<i) of any foreign applicadon(s) for patent or inventor' 
certificate listed below and have also identified below any foreign application for patent or inventor's certificate having a filing date before ths 
of the application on \^ucih priority is claimed: 



"h EARLIEST FOREIGN APPLICATION(S), IF ANY. HUeP PRIOR TO THE FILING DATE OF THE APPUCATION 


M l APPLICATION NUMBER 


COUNTRY 


DATE OP FILING 
(day, mondi. year) 


PRIORITY 
CLAIMED 








YES □ NO □ 








YES a NO □ 



I hereby claim tbe benefit uader Tide 35, United States Code, §119(e) of any Unice<l States provisional application(s) listed below. 



APPUCATION NUMBER 


FILING DATE 











Iheteljy claim the benefit ^der Title 35, United Svaxss, Code, §120 of any United States appUcation(s) listed below ajid, insofar a* the subje< 
matter of each of the claims of this applicatiozi is not disclosed ia the prior United Slates application in the manner provided by the fir- 
paragn^h of lltle 35, Unhed States Code §112, 1 aclcnowledge die duty to disclose itiformation. which is material to patentabili^ as define 
in Tide 37. Code of Federal Regulations, 5 1^6 ^hich became available between the filing date of the prior application and the national or PC 
intexnadonal filing date of this application: 



APPUCATION SERIAL NO. 


FILING DATE 


STATUS 


PATENTED 


PENDING 


ABANDONED 


08/917,761 


Augu5t 27, 1997 




X 















POWER OF ATTORNEY: As a named inventor, I hereby appoint S. Leslie Misrock (Reg. No, 1 8872), Haxiy C. Jones, m (Reg. No. 20280 

Beq A. Tetziaa (Reg. No. 20060), Gerald L Flintoft (Reg. No, 20823), David Wcild, m No, 21094), Jonathan A. MarshaU (Reg. Ni 

24614), Bany D. Rein (Reg, No. 22411), Stanton T. Lawrence, JE (Reg. No. 25736), Isaac Jarlcovsty (Reg. No. 22713). Joseph V. Colaianj - ^.^ 

(Reg. No. 20019), Charles E. McKenney CRfig. No. 22795), Philip T. Shannon (Reg. No. 24278), Francis E. Morris (Reg. No, 24615), Charif 

E, XCller (Reg. No. 24576), Gidon D, Stem (Reg. No. 27469), John J. Lauter, Jr. (Reg. No. 27814), Brian M. Poi«fiant (Reg. No, 28462 

Brian D. Coggio (Reg. No, 27624), Roiy J. Radding (Reg. No. 2$749), Stephen L Harbulak (Reg. No. 291^^. Donald J. Goodell (Reg, Nt 

19766), James N. Palik (Reg. No. 25510), Thomas E. Fricbel (Reg. No. 29258), Laura A. Coruzzi (Reg. No. 30742), JeDtaifcr Gordoa (Rei 

No. 30753), Jon R. Stark (Reg. No. 3011 1), Allan A. Fanucci (Reg. No. 30256), Geraldine F. Baldwin (Reg. No. 3 1232), Victor N. Balanc 

(Reg. No. 31231), Samuel B. Abrams (Re^. Ko, 30^5), Steven L Wallach (Reg, No. 35402). Marcia H. Simdeen (Reg. No. 30893), Pa- 

J. Zegger (Reg. No. 33821), Edmond R. Bannon (Reg. No. 32110), Bruce J. Barker (Reg. No. 33291), Adriane M, Antler (Reg. No. 32605 

Thomas G. Rowan (Reg. No. 34419), Aim L. Gisolfi (Reg, No. 31956), Mark A. Farley (Reg. No. 33170), and James G. Markey (Reg. 

31636), all of Pennie & Edmonds xxp, whose addresses are 1155 Avenue of die Americas, New York, New York 10036, 1667 K Street N,W 

Washington, DC 20006 and 3300 Hiilview Avenue, Palo Alto, CA 94304, and each of chem, my aoontcys, to prosecute this appUcatioa. ar 

to transact all business in the Patent and Trademark Oj^ce connected therewirfi. 



PENNE & EDMONDS ^ DOCKET NO. 2269^7 



SEND CORRESPONDENCE TO: 



HJIXNAME 
_OF mVENTOR 



RESIDENCE & 
CITIZENSHIP 



POST OFHCE 
ADDRESS 



FUIXNAME 
OF INVENTOR 



RESIDH NCE A 

crnzENsmp 



POST OFHCE 
ADDRJESS 



FUIXNAME 
OF INVENTOR 



RESIDENCE & 
CmZENSHIP 



K)$TOmCE 
ADDRESS 



FULL NAME 
OF INVENTOR 



RHSSOE NCS A 
CmZENSHIP 



POST OFHCE 
ADDRESS 



PULL NAME 
OF INVENTOR 



I RESIDENCE & 

cmzENsmp 



PENNIE & EDMONDS tip 
1667 K STREET, N.W. 
WASHINGTON, D.C. 20006 



LASTKaME 

Ballard 



cmr 

Lloyd Harbor 



16 West Neck Court 



Claudio 



DIRECT TELEPHONE CALLS TO- 
PENNIE & EDMONDS ixp DOCKETING 
(202) 49(?-4400 



STATB OR PORHCN COUNTRY 

New YorJc 



OTV 

Uoyd HartKir 



cmr 



OTV 



POST OFHCE 
ADDRESS 



FULL NAME 
OF INVENTOR 



RESIDENCE & 
CmZENSHlP 



POSTOmCE 
ADDRESS 



FIRST NAM£ 



STATB OR POAaCM COWTBY 



ctrr 



STATE OR POanON COUNDtY 



FIKTNAMfi 



CrtT 



FIRST NaMB 



ST ATB OR FORQQf COUHTRlY 



R. 



COUNTRY Of CanzENSHrp 
United States 



STATH OR, COUHTKy 

New York 



MmOLe KAMB 



zircoofi 
11743 



COVNTST Of: cmZENSHIP 



STATBORCOOhnXY 



MIDDLBNAMB 



aPCODE 



5TATE OS. COWTOY 



MIDDLE NAM^ 



ZIP CODE 



COVKTRY OF CmZENSHIP 



STATS. OR COUNTTtY 



ZIFCOPB 



NODDLE NAMB 



coukthy op cmzENSHi^ 



STATE OR COUNTRY 



ZIP CODE 



MIOOL5 NAME 



coumnY OF crnzENsmp 



-StAXe 09. COUNTRY 



^C^B 



bclicvid' 'j'^UuT^, ftt'su^m^^lSTm^^^^^ ^ '-^^ on infomndon belief an 

mAy jeopardize the validity of the appUcadoA or any S S"^^n ^ "^'^'^^"^ 





SIGNATURE OF INVENTOR 204 



SIGMATURH OF INVENTOR 202 



DATH 



SIGNATXJRS op inventor 2Q5 



SIGNATURE OF INVENTOR 203 



DATE 



SIGNATURE OP INVENTOR 206 



DATS 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In the paieni 
application of: 



Claudia R. 3aiUrd 



Serial No: 08/ 9 17 J6 1 

Filed: August 27, 1997 

Art Unit- 3642 
Examiner Career, M. 

Attorney Docker No. : 2000976-0009 

For: REMOTE IMAGE CAPTURE WTTK CENTR.ALIZED 



PROCESSING .AND STOR.AGE 



Caminissioncr for Patents 
Wasmnsfton, D C 2023 1 



SUPPLE.MRNTAL ?0\VTR OF ATTORNEY 



Sir 



I hereby appoint i Michael Maninez de .^^dino. Rajj. No, j7 173, Mark A. Tivlcr. Reg 
No. 35. 'G6, Philip D Lai:e, Reg No 41. HO and David E. BaJccr, 42,2Si, ail aitcnieys of :he 
arm of McGuire, Woods, Battle & Bcothc LLP, One James Center. 501 Eos: Carv* Screet. 
Richmond, Virginia 23219, teiephone aumber (304) 775-1033. as suppiementai attorneys ro 
prosecute the appiicarion identincd above ard :ran5ac: ai! bu5iaes3 in the Patent and Trademark 
Office connected therewith. 

! represent the assignee of record of 'Jre sntir? 'nter*n A c^rificaie under 37 CFR Sectic 
3.73(b) is enclosed. 



Correspondence direc:ed :o 
J. Midiaei Martinez de Andino, Esquire 
McGuire Woods Battle & Soothe LLP 
One iamss Center 
90! Eas: Car/ Street 
Richrnond. Virginia 23219-4030 
Telephone (304) 775-1033 



Rispecifully submitted 




Cfaudic R. Ballard 
President 

CSP Holdings. LLC 



